Token Classification and Standards

Introduction

A blockchain token is a digitally represented right, value, claim, permission, or object recorded and transferred through a distributed ledger. Tokens are not all economically or technically equivalent. A token may represent money, access to a service, voting power, an investment contract, a physical asset, a unique digital item, or a non-transferable credential. Correct classification is therefore essential for token design, regulatory analysis, wallet development, exchange listing, accounting, and risk management.

Token classification has two related but distinct dimensions:

1. Economic or legal classification—what the token represents and what rights it gives its holder.
2. Technical classification—how the token is represented and operated by a blockchain standard or smart contract.

A token can belong to more than one economic category. For example, a token may provide access to a platform while also possessing characteristics of an investment contract. Similarly, a stablecoin may be implemented as a fungible token under ERC-20, while a collection of unique certificates may use ERC-721.

Learning Objectives

By the end of this chapter, students should be able to:

• distinguish utility, payment, governance, security, asset-backed, stable, non-fungible, and soulbound tokens;
• explain why token classifications may overlap;
• identify major fungible, non-fungible, semi-fungible, and permissioned token standards;
• compare the capabilities and limitations of ERC-20, ERC-721, ERC-1155, and related standards;
• select an appropriate token standard for a practical application;
• evaluate regulatory, governance, custody, and technical risks in token design.

1. Foundations of Token Classification

1.1 Fungibility and uniqueness

A fungible token is interchangeable with another unit of the same class. One unit has the same functional value as any other unit, subject to market conditions. Currency units, loyalty points, and many governance tokens are fungible.

A non-fungible token (NFT) is individually identifiable. Each token may have a distinct identifier, metadata, ownership history, or associated rights. A land title, digital artwork, event ticket, or game character may be represented as an NFT.

A semi-fungible token combines both properties. Units may be interchangeable within a batch but distinct from units in another batch. For example, 1,000 tickets for the same concert may be mutually interchangeable before seat allocation, while VIP and standard tickets belong to different classes.

1.2 Token versus coin

A coin is the native asset of a blockchain, such as BTC on Bitcoin or ETH on Ethereum. A token is generally issued through a protocol, smart contract, or token program running on an existing blockchain. The distinction is useful but not absolute: everyday usage often calls both coins and tokens “cryptoassets.”

1.3 Rights, claims, and functions

Classification should begin with the rights attached to the asset rather than its marketing name. Relevant questions include:

• Does the holder receive access to a service?
• Can the token be used to pay for goods or network fees?
• Does it provide voting or proposal rights?
• Does it represent a claim on profits, debt, assets, or cash flows?
• Is it redeemable for fiat currency or commodities?
• Is it unique, transferable, or deliberately non-transferable?
• Who controls issuance, redemption, upgrades, and freezing?

A token’s name does not determine its legal status. Calling an instrument a “utility token” does not prevent regulators from examining its economic substance.

2. Major Economic and Functional Categories

2.1 Utility tokens

A utility token is designed to provide access to a product, service, feature, or network function. Examples include tokens used to pay transaction fees, obtain computing resources, access premium software, or receive discounts.

A sound utility-token design links demand to actual use. Important design questions include whether users must hold the token, whether they can purchase it only when needed, and whether the issuer can arbitrarily increase supply. A token sold before a service exists may create expectations of future appreciation and may consequently raise securities-law concerns.

Utility tokens may also be used for staking, fee discounts, or resource allocation. These additional functions can change the risk profile and should be analysed separately.

2.2 Payment tokens

A payment token is primarily intended to function as a medium of exchange, unit of account, or store of value. Bitcoin is the classic example of a cryptoasset designed for peer-to-peer payment without a central issuer. Stablecoins are also commonly used for payments, although their value mechanism differs from that of unbacked cryptoassets.

Payment tokens face practical challenges:

• price volatility;
• limited merchant acceptance;
• transaction throughput and confirmation time;
• user-interface and custody risks;
• money-laundering and sanctions concerns;
• tax and accounting treatment.

A payment token’s usefulness depends not only on its code but also on liquidity, settlement reliability, legal acceptance, and the availability of wallets and payment infrastructure.

2.3 Governance tokens

A governance token gives holders some ability to influence protocol parameters, treasury spending, upgrades, fee schedules, or admissions to a community. Voting may be direct, delegated, quadratic, reputation-weighted, or based on locked token balances.

Token voting is not automatically democratic. Concentrated ownership, delegated voting, low participation, voter apathy, and insider coordination may give a small group effective control. Governance systems should specify quorum, proposal thresholds, voting periods, execution delays, emergency powers, and conflict-of-interest rules.

A common governance design is vote delegation. Holder A may retain economic ownership while authorising representative B to vote. This can improve participation but may also increase the influence of large delegates.

2.4 Security tokens

A security token represents an investment interest or financial claim, such as equity, debt, revenue participation, or a share in an investment vehicle. The classification depends on the rights and circumstances of issuance, not merely on the use of blockchain technology.

Security tokens may provide:

• dividends or revenue distributions;
• repayment of principal and interest;
• voting rights in an enterprise;
• fractional ownership of an investment asset;
• contractual claims against an issuer.

They may require identity verification, transfer restrictions, approved trading venues, investor disclosures, reporting, and regulated custody. A permissionless transfer function may be technically possible but legally inappropriate.

2.5 Asset-backed tokens

An asset-backed token is linked to a reserve or reference asset. The reserve may consist of fiat currency, government securities, commodities, real estate, carbon credits, or another cryptoasset. The token may provide a redemption claim, a beneficial interest, or merely price exposure.

The key analytical distinction is between backing and legal claim. A token can be economically supported by assets without giving holders a direct enforceable claim to those assets. Assessment should therefore examine:

• reserve ownership;
• custody and segregation;
• valuation methodology;
• audit or attestation practices;
• redemption rights and timing;
• insolvency treatment;
• issuer and custodian risks.

2.6 Stablecoins

A stablecoin aims to maintain a relatively stable value against a reference unit, commonly a national currency. Stability mechanisms include:

1. Fiat- or asset-reserved stablecoins—tokens are supported by reserves such as cash or short-term government instruments.
2. Crypto-collateralised stablecoins—users lock cryptoassets as collateral, often with overcollateralisation.
3. Algorithmic or endogenous designs—supply and incentives are adjusted through rules intended to influence market price.
4. Hybrid designs—combine reserves, collateral, market-making, and algorithmic controls.

Stability is a target, not a guarantee. A simple reserve ratio can be expressed as:

where R is the reserve ratio, Vᵣ is the current value of eligible reserves, and Vₜ is the redemption value of outstanding tokens. The formula assumes that reserves are correctly valued, available for redemption, and legally accessible. A ratio of 1 does not eliminate liquidity, custody, valuation, or legal risks.

For a crypto-collateralised system, the collateralisation ratio is commonly expressed as:

where V𝚌 is collateral value and Vₗ is the value of liabilities or issued stablecoins. The ratio must be interpreted with the system’s liquidation threshold, price volatility, and oracle assumptions.

2.7 Non-fungible tokens

An NFT is a unique token within a collection or contract. Its uniqueness may represent an image, licence, certificate, ticket, identity attribute, game item, or physical asset. Ownership of an NFT does not automatically transfer copyright, trademark rights, or control of an associated off-chain asset. Those rights must be defined contractually.

NFT design requires attention to metadata. Metadata may be stored fully on-chain, in decentralised storage, or on a conventional server. If an NFT points to a mutable web URL, the token may persist while the referenced content changes or disappears. Users should distinguish token ownership, metadata availability, and intellectual-property rights.

2.8 Soulbound and non-transferable tokens

A soulbound token (SBT) is generally designed to be non-transferable and associated with a person, organisation, or account. Possible uses include educational credentials, professional certifications, membership records, reputation signals, and attestations.

Non-transferability can reduce resale fraud but introduces serious privacy and recovery issues. A lost private key may prevent access to important credentials. Publicly visible credentials may enable profiling or discrimination. Good designs use selective disclosure, revocation, expiration, and recovery procedures. In many cases, an attestation system that reveals claims only with the holder’s consent is preferable to permanently public personal data.

3. Technical Token Standards

A token standard defines expected interfaces and behaviours. Standards improve interoperability because wallets, exchanges, explorers, and applications know how to interact with compliant contracts. Compliance with a standard does not guarantee security, legal compliance, or economic value.

3.1 ERC-20: fungible tokens

ERC-20 is the widely adopted Ethereum standard for fungible tokens. Its conventional interface includes functions such as:

• totalSupply();
• balanceOf(account);
• transfer(to, amount);
• approve(spender, amount);
• allowance(owner, spender);
• transferFrom(from, to, amount);
• Transfer and Approval events.

The allowance mechanism enables a decentralised application to spend tokens on behalf of a user. It also creates approval risks: an excessive or unlimited allowance can permit a malicious or compromised spender to transfer approved funds.

Decimals in an ERC-20 contract are a display convention, not a change to the underlying integer accounting. If a token uses 18 decimals, a displayed balance of 2.5 corresponds to 2.5 × 10¹⁸ base units. Contracts must use integer arithmetic and clearly document decimal assumptions.

3.2 ERC-721: unique NFTs

ERC-721 represents individually identifiable tokens. Each token has a tokenId, and ownership is tracked per identifier. Common operations include minting, transferring, approving an operator, querying ownership, and reading token metadata.

ERC-721 is suitable where every item is distinct, such as a deed, collectible, or individually numbered certificate. It may be inefficient for issuing large quantities of identical items because each token is handled separately.

3.3 ERC-1155: multi-token and semi-fungible assets

ERC-1155 supports multiple token IDs within one contract. Each ID can represent a fungible, non-fungible, or semi-fungible class. Batch transfer functions reduce transaction overhead for applications such as games, event tickets, and inventory systems.

For example, token ID 10 might represent 100,000 identical game coins, while token ID 20 might represent a limited-edition sword. The standard supports both quantities and identifiers, but the application must define what each ID means and how metadata behaves.

3.4 ERC-777 and ERC-1363

ERC-777 proposes richer token interactions, including operator functionality and hooks that can notify recipient contracts. Hooks may improve composability but increase implementation complexity and re-entrancy considerations.

ERC-1363 extends fungible-token behaviour with transfer-and-call and approve-and-call patterns. These can improve user experience when tokens must trigger a contract action, but developers must validate recipient contracts and guard against unexpected execution paths.

3.5 ERC-2981: NFT royalty information

ERC-2981 provides a standard method for communicating royalty information for NFTs. It does not by itself force every marketplace or user to pay royalties, and it does not establish copyright ownership. Royalty enforcement depends on marketplace policies, transfer restrictions, or additional technical mechanisms.

3.6 ERC-3643 and permissioned tokens

ERC-3643 is associated with permissioned, identity-aware tokens. Such systems can check whether a wallet is authorised, whether an investor satisfies eligibility requirements, and whether transfers comply with restrictions. This approach is relevant to regulated securities and tokenised real-world assets.

Permissioned tokens introduce centralisation and governance dependencies. Issuers or compliance agents may be able to freeze, recover, reject, or force transfers. These powers may be necessary, but they should be disclosed and subject to clear controls.

3.7 Standards on other networks

Token standards are ecosystem-specific. Examples include:

The label “standard” may mean a formal proposal, a widely implemented interface, or a platform convention. Bitcoin inscription systems, for example, differ conceptually from account-based smart-contract token standards and should not automatically be treated as equivalent to ERC-20 or ERC-721.

4. Choosing a Token Standard

A professional selection process should begin with business and legal requirements rather than a preference for a particular chain.

The decision should also consider transaction cost, wallet support, upgradeability, privacy, metadata persistence, transfer restrictions, recovery, auditability, and interoperability.

5. Applied Case: Tokenising Professional Certificates

Background

Consider an illustrative organisation, Northbridge Skills Institute, which wants to issue blockchain-verifiable diplomas. It wants employers to verify certificates while preventing students from selling or transferring them.

Problem

A conventional NFT standard would make each certificate unique but transferable. Transferability could allow a person to present another student’s certificate as their own. A public certificate could also expose unnecessary personal information.

Analysis

The economic function is not payment, investment, or ownership of an asset. It is an attestation of achievement. The credential should therefore be non-transferable, revocable, and privacy-conscious. The institute must also define whether the token proves only that a certificate was issued or whether it contains the complete academic record.

Approach

Northbridge uses an account-bound credential system with the following controls:

• a unique credential identifier;
• an issuer signature or verifiable attestation;
• a revocation registry;
• expiration for time-sensitive qualifications;
• minimal public metadata;
• a student-controlled wallet and recovery process;
• selective disclosure of programme, date, or grade;
• an issuer governance policy for corrections and fraud reports.

A conventional transferable ERC-721 token is rejected because transferability conflicts with the credential’s purpose. An ERC-1155 design is also unsuitable if every credential must be individually attributable. A soulbound or attestation-based approach is more appropriate, although the institute must address lost keys and identity recovery.

Outcome

Employers can verify authenticity without relying entirely on a paper document or a central web page. Students retain control over presentation, while the institute retains authority to revoke fraudulent or incorrectly issued credentials. Privacy remains a continuing obligation: public blockchains are not appropriate places for unnecessary personal data.

Learning points

1. The use case determines the required token properties.
2. Transferability is a functional design choice, not a default benefit.
3. Technical standards do not independently solve identity, privacy, or governance problems.
4. Revocation and recovery are essential for long-lived credentials.

6. Risks, Regulation, and Governance

6.1 Classification risk

A project may describe a token as utility-based while its sale, profit expectations, marketing, and issuer promises create investment characteristics. Classification should be assessed by qualified legal professionals in each relevant jurisdiction. Regulatory categories differ, and cross-border distribution can create multiple obligations.

6.2 Smart-contract risk

Common risks include flawed access control, re-entrancy, integer errors, faulty upgrade mechanisms, compromised keys, oracle manipulation, and incorrect token accounting. Audits reduce but do not eliminate risk. Testing should include unit tests, integration tests, adversarial scenarios, invariant checks, and controlled deployment procedures.

6.3 Custody and operational risk

Users may lose private keys, approve malicious contracts, or interact with counterfeit tokens. Issuers should publish verified contract addresses, use secure key management, monitor abnormal transfers, and provide clear incident procedures.

6.4 Centralisation and administrative powers

An issuer may retain mint, pause, blacklist, freeze, upgrade, or forced-transfer privileges. These may support compliance or emergency response, but they create counterparty and censorship risks. The powers, limits, approval process, and event logs should be disclosed.

6.5 Privacy and ethical issues

Public ledgers can make ownership histories permanently observable. Linking wallet addresses to real identities may expose financial behaviour. Systems involving credentials, health information, employment, or reputation require data minimisation and, where possible, off-chain storage with cryptographic proofs or selective disclosure.

6.6 Environmental and social considerations

The environmental impact of a token system depends substantially on the underlying consensus mechanism, transaction activity, hardware, and energy mix. A token standard itself does not determine total environmental impact. Social risks include speculative losses, exclusion caused by transaction fees, market manipulation, and unequal governance power.

7. Contemporary Developments and Best Practices

Token standards increasingly support real-world assets, regulated transfers, account abstraction, privacy-preserving credentials, and cross-chain interoperability. However, interoperability bridges and message-passing systems introduce additional trust assumptions. A token represented on one chain may be locked while a wrapped representation circulates elsewhere; the safety of that representation depends on the bridge’s validators, contracts, and recovery procedures.

Best practices include:

• document the token’s rights, supply, and governance clearly;
• separate economic claims from technical implementation;
• use established standards unless a documented requirement justifies deviation;
• verify contract source code and publish addresses;
• audit and independently review critical contracts;
• implement least-privilege administration and multisignature controls;
• protect user privacy and avoid placing personal data on-chain;
• define minting, burning, redemption, freezing, and recovery procedures;
• test wallet, marketplace, and indexer compatibility;
• obtain jurisdiction-specific legal and tax advice;
• communicate risks without implying guaranteed returns.

Chapter Summary

Token classification concerns both what a token represents and how it operates technically. Utility tokens provide access or functionality; payment tokens facilitate exchange; governance tokens support collective decision-making; security tokens represent investment or financial claims; asset-backed tokens reference reserves or physical assets; stablecoins seek relatively stable value; NFTs identify unique items; and soulbound tokens provide non-transferable credentials or attestations. These categories may overlap, and labels do not determine legal treatment.

Technical standards provide common interfaces and improve interoperability. ERC-20 is primarily used for fungible tokens, ERC-721 for unique NFTs, ERC-1155 for multi-token and semi-fungible systems, ERC-2981 for royalty information, and ERC-3643 for permissioned, identity-aware tokenisation. Other ecosystems use standards such as SPL, BEP-20, and TRC-20.

Selecting a standard requires analysis of fungibility, uniqueness, transferability, privacy, compliance, transaction cost, metadata, custody, governance, and recovery. Standards do not eliminate smart-contract, regulatory, market, or ethical risks. Professional token design begins with the rights and use case, then selects a suitable technical implementation.

Key Terms

Asset-backed token: A token linked to reserves or a reference asset.

ERC-20: A widely used Ethereum interface for fungible tokens.

ERC-721: An Ethereum standard for individually identifiable NFTs.

ERC-1155: A multi-token standard supporting fungible, non-fungible, and semi-fungible classes.

Fungibility: Interchangeability of units within the same class.

Governance token: A token providing voting or protocol decision rights.

NFT: A non-fungible token with a distinct identifier or associated properties.

Payment token: A token primarily intended for exchange or settlement.

Permissioned token: A token whose ownership or transfer depends on defined eligibility rules.

Royalty: A payment or payment claim associated with later use or transfer of an asset.

Security token: A token representing an investment, financial claim, or regulated security interest.

Semi-fungible token: A token that is interchangeable within a class but distinct across classes.

Soulbound token: A generally non-transferable token associated with an identity or account.

Stablecoin: A token designed to maintain relatively stable value against a reference asset.

Token standard: A technical interface and behavioural convention for blockchain assets.

Utility token: A token used to access a service, network, product, or feature.

Verifiable credential: A digitally signed claim whose authenticity can be checked independently.

Wrapped token: A representation of an asset on another blockchain or system, dependent on a custody or bridging mechanism.

Review Questions

Short Answer Questions

1. What is the difference between a fungible token and an NFT?
2. Why can a token have more than one economic classification?
3. State two risks associated with stablecoins.
4. What is the main purpose of ERC-1155?
5. Why might a professional credential use a soulbound or attestation-based design?

Long Answer Questions

1. Compare utility, payment, governance, and security tokens, including their principal rights and risks.
2. Explain how ERC-20, ERC-721, and ERC-1155 differ in structure and application.
3. Discuss the distinction between asset backing and a legally enforceable redemption claim.
4. Analyse the privacy, recovery, and governance challenges of soulbound tokens.
5. Describe a systematic process for selecting a token standard for a new blockchain project.

Analytical / Application Questions

1. A company wants to issue tokens representing fractional interests in rental income from property. Classify the likely economic characteristics, identify regulatory concerns, and recommend technical features.
2. A game needs interchangeable gold units, unique legendary weapons, and batches of identical event tickets. Recommend suitable token standards for each asset and justify your choices.
3. A stablecoin has reserves worth 95 million units and outstanding redemption claims worth 100 million units. Calculate its reserve ratio using R = Vᵣ ÷ Vₜ, interpret the result, and identify two assumptions that must be checked before relying on it.

Multiple Choice Questions with Answers

Question 1

Which property most directly distinguishes a fungible token from an NFT?

A. Fungible tokens are interchangeable within their class

B. Fungible tokens must always be backed by fiat currency

C. NFTs cannot be transferred

D. NFTs must represent physical objects

Correct Answer: A. Fungible tokens are interchangeable within their class

Question 2

Which token category primarily provides access to a product, service, or network function?

A. Security token

B. Utility token

C. Soulbound token

D. Asset-backed token

Correct Answer: B. Utility token

Question 3

What is the principal purpose of a governance token?

A. To guarantee a stable exchange rate

B. To prove copyright ownership

C. To provide participation in specified decisions

D. To make every asset non-transferable

Correct Answer: C. To provide participation in specified decisions

Question 4

Which standard is most commonly associated with fungible tokens on Ethereum?

A. ERC-20

B. ERC-721

C. ERC-2981

D. ERC-1155 only for NFTs

Correct Answer: A. ERC-20

Question 5

Which standard is especially suitable for multiple token classes and batch transfers?

A. ERC-20

B. ERC-1155

C. ERC-2981

D. TRC-20

Correct Answer: B. ERC-1155

Question 6

What does ERC-2981 primarily communicate?

A. A blockchain’s consensus rules

B. NFT royalty information

C. A stablecoin’s reserve balance

D. A user’s private key

Correct Answer: B. NFT royalty information

Question 7

A token has reserves valued at 95 million and redemption claims of 100 million. What is its reserve ratio?

A. 0.095

B. 0.95

C. 1.05

D. 95

Correct Answer: B. 0.95

Question 8

Which feature is most characteristic of a soulbound token?

A. Guaranteed appreciation

B. Non-transferability linked to an account or identity

C. Automatic fiat redemption

D. Interchangeability with every token

Correct Answer: B. Non-transferability linked to an account or identity

Question 9

Why does compliance with a token standard not guarantee legal compliance?

A. Standards define interfaces, not the full legal character of rights and issuance

B. Standards apply only to physical assets

C. Standards prevent all transfers

D. Standards eliminate issuer control

Correct Answer: A. Standards define interfaces, not the full legal character of rights and issuance

Question 10

Which design is generally most appropriate for an individually identifiable digital certificate that must not be sold?

A. A freely transferable fungible token

B. A payment coin

C. A non-transferable credential or attestation

D. An uncollateralised stablecoin

Correct Answer: C. A non-transferable credential or attestation