Tokens and Industry Standards

Introduction

Blockchain tokens are programmable representations of value, rights, assets, or access. A token may represent a currency, a unit of ownership, a collectible, a licence, a vote, an in-game item, or a claim on a service. Smart-contract standards make these representations interoperable: wallets, exchanges, marketplaces, custodial systems, analytics tools, and decentralised applications can interact with tokens through known functions and events.

Standards do not, however, guarantee that a token is safe, valuable, legally compliant, or economically sustainable. A contract can satisfy an interface while implementing harmful transfer restrictions, misleading metadata, uncontrolled issuance, or poorly designed incentives. Professional token engineering therefore combines Solidity implementation, interface compliance, security review, economic analysis, governance, and responsible communication.

Learning Objectives

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

1. Explain the purposes and design trade-offs of ERC-20, ERC-721, and ERC-1155.
2. Implement and evaluate metadata, royalty, and permit mechanisms.
3. Distinguish interface compliance from behavioural and security compliance.
4. Analyse supply, allocation, emissions, vesting, and token utility.
5. Apply testing, access control, audit, and governance practices to token issuance.
6. Evaluate regulatory, ethical, consumer-protection, and operational risks.

1. What Is a Token Standard?

An Ethereum Improvement Proposal (EIP) documents a proposed change, interface, or convention. Some EIPs become widely adopted standards. The term “ERC” is commonly used for Ethereum Request for Comment standards, although the underlying proposal may be an EIP. A standard generally specifies function signatures, events, return values, and behavioural expectations.

A useful distinction is:

• Interface compliance: required functions and events exist with the correct signatures.
• Semantic compliance: functions behave as the standard expects.
• Security quality: the implementation resists misuse, unexpected calls, privilege abuse, and known vulnerabilities.
• Application suitability: the standard is appropriate for the intended business and user requirements.

For example, a contract may expose balanceOf and transfer, yet still contain an owner-controlled blacklist that makes transfers selectively impossible. Such a contract may resemble ERC-20 technically but presents important economic and governance risks.

2. ERC-20: Fungible Tokens

ERC-20 defines a common interface for fungible tokens. Fungibility means that one unit is interchangeable with another unit of the same token. A token used as a points balance, settlement asset, or voting unit usually has this property.

The principal functions are:

The important events are Transfer and Approval. Indexers and applications depend on these events to reconstruct balances and allowances.

2.1 Units and Decimals

ERC-20 balances are integer values. The decimals() function is a display convention rather than a change to the underlying arithmetic. If a token uses d decimals, a displayed quantity q is represented on-chain as:

where u is the integer base-unit amount. For an 18-decimal token, 2.5 displayed tokens are represented as 2,500,000,000,000,000,000 base units. Contracts must perform calculations using integers and must avoid assuming that every token has 18 decimals.

2.2 Allowances and Approval Risk

The allowance mechanism permits a spender—often an exchange or protocol—to transfer tokens on behalf of an owner. A common operational risk arises when an allowance is changed directly from one non-zero value to another. Depending on transaction ordering, a spender may use the old allowance before the new transaction is mined. Interfaces commonly reduce this risk by first setting the allowance to zero or by using safer allowance-update patterns.

An allowance is a permission, not a balance. A protocol should request only the amount and duration necessary for its function. Users should revoke approvals that are no longer required.

2.3 ERC-20 Implementation Practices

A production implementation should normally use a well-reviewed library, such as OpenZeppelin Contracts, rather than independently rewriting transfer and allowance logic. Design decisions include:

• fixed supply versus mintable supply;
• who may mint or burn;
• whether the cap is immutable;
• pause and emergency controls;
• handling of tokens sent accidentally to the contract;
• upgradeability and storage-layout management;
• decimals and display precision;
• event completeness and indexing.

A mint function must enforce its supply policy. If S is current supply, m is a mint amount, and C is a maximum cap, a capped design requires:

This condition applies whenever minting occurs and assumes that S, m, and C are measured in the same base units and that arithmetic cannot overflow. Solidity 0.8 and later provides checked arithmetic by default, but explicit policy checks remain necessary.

3. ERC-721: Non-Fungible Tokens

ERC-721 represents individually identifiable, non-fungible tokens. Each token has a unique tokenId. Ownership is recorded per identifier, so token 17 and token 18 may have different metadata, histories, and values.

Core functions include balanceOf, ownerOf, approve, getApproved, setApprovalForAll, isApprovedForAll, transferFrom, and safe-transfer functions. The Transfer, Approval, and ApprovalForAll events support indexing and application integration.

3.1 Safe Transfers

A safe transfer checks whether the recipient is a contract. If it is a contract, the recipient must implement the expected receiver callback. This prevents tokens from being sent to contracts that cannot recognise or return them. Safe transfer is not a guarantee that the recipient is economically trustworthy; it is a compatibility safeguard.

3.2 Token Identity and Metadata

An ERC-721 token is identified by the pair consisting of its contract address and tokenId. A tokenId alone is not globally unique. The tokenURI(tokenId) function commonly returns a URI describing the token. The referenced metadata may be JSON stored on IPFS, another content-addressed system, a conventional web server, or generated by the contract.

A typical metadata object may include name, description, image, and attributes. Metadata design must address permanence, content integrity, update authority, and availability. A URI pointing to a mutable web server does not provide the same assurance as content-addressed storage.

4. ERC-1155: Multi-Token Contracts

ERC-1155 supports multiple token types in one contract. Each id may represent a fungible token, a non-fungible token, or a semi-fungible class. A game, for example, can represent coins, swords, and unique characters through one contract.

Important functions include balanceOf, balanceOfBatch, setApprovalForAll, safeTransferFrom, and safeBatchTransferFrom. Batch operations can reduce transaction overhead when many assets are transferred together. Receiver acceptance checks are provided through ERC-1155 receiver interfaces.

The principal events are TransferSingle, TransferBatch, and ApprovalForAll. The standard URI pattern can substitute the token identifier into a URI template. Developers must correctly encode the identifier in the required hexadecimal form and ensure that the metadata service follows the documented convention.

4.1 Choosing Between ERC-721 and ERC-1155

The choice should follow the asset model, not fashion. A collection of 10,000 individually identified works can use ERC-721, while tickets with multiple classes and repeated inventory may be better represented by ERC-1155.

5. Royalties and Secondary Sales

ERC-2981 standardises how a contract communicates royalty information. Its royaltyInfo(tokenId, salePrice) function returns a recipient and royalty amount for a given sale price. The standard does not force a marketplace to pay the royalty, and it does not enforce a transfer fee on-chain.

If the royalty fraction is r basis points and the sale price is P, the royalty amount is:

Here, P and R use the payment token’s smallest unit, r is an integer number of basis points, and 10,000 basis points equal 100%. The implementation must ensure that r ≤ 10,000; many projects impose a lower governance limit. Rounding is normally specified by integer division. The contract should also define the royalty receiver and behaviour when the receiver is changed.

Royalties are therefore a signalling and integration standard, not an automatic economic entitlement. Marketplaces may honour, ignore, or replace them, depending on their architecture and policies.

6. Permits and Signature-Based Approvals

Traditional ERC-20 approval requires an on-chain transaction from the token owner. EIP-2612 permits a user to sign an approval off-chain. A relayer or protocol submits the signature, allowing approval and a subsequent action to be combined or sponsored.

A permit normally includes the owner, spender, value, nonce, deadline, and EIP-712 domain data. The signed message must be bound to the correct contract, chain, and operation. The nonce prevents replay of the same signature, while the deadline limits its validity.

A conceptual permit validity condition is:

The condition is meaningful only when the contract also verifies the signature, domain separator, owner, spender, value, and expected nonce. Implementations must account for chain identifiers, contract addresses, signature malleability, and smart-contract wallets. A signature is not proof that a user understands every downstream action; interfaces must present clear human-readable signing information.

7. Tokenomics and Supply Design

Tokenomics describes how a token is created, distributed, used, governed, and removed from circulation. It should be treated as a system of incentives and constraints rather than as a marketing slogan.

7.1 Supply and Allocation

Let total supply be divided among categories such as community, treasury, team, investors, ecosystem incentives, and liquidity. A basic allocation constraint is:

where Aᵢ is the allocation to category i and S_T is total planned supply. If allocations are expressed as percentages pᵢ, then:

These identities assume categories do not overlap and that all allocations are measured against the same supply definition. A project must state whether it means maximum supply, initial supply, circulating supply, or fully diluted supply.

Circulating supply changes when tokens are unlocked, minted, burned, or otherwise become available to the market. A simple supply identity is:

where Sₜ is supply at time t, Mₜ is tokens minted during the interval, and Bₜ is tokens burned. Locked tokens may be included in total supply while excluded from circulating supply; definitions must therefore be explicit.

7.2 Emissions, Vesting, and Incentives

Vesting reduces the risk of immediate concentration and aligns long-term participation. A schedule may include a cliff followed by linear release. If V tokens vest linearly over n equal periods after a cliff, the amount per period is:

This is a planning formula, not a complete contract specification. A real contract must define timestamps, rounding, revocation rights, beneficiary changes, and treatment of partial periods.

Token utility should be concrete: access, payment, collateral, governance, reputation, or another necessary function. A token whose only apparent utility is attracting later purchasers presents significant ethical, economic, and regulatory risk.

8. Compliance and Testing

A professional evaluation should include the following layers:

1. Compilation and interface tests: verify function signatures, events, return values, and supported interfaces.
2. Unit tests: test transfers, minting, burning, approvals, metadata, royalties, permits, and boundary conditions.
3. Property and invariant tests: verify that balances do not become negative, supply limits are preserved, and unauthorized accounts cannot mint.
4. Integration tests: test wallets, marketplaces, receiver contracts, indexers, and relayers.
5. Adversarial tests: examine reentrancy, replay, front-running, denial of service, approval misuse, and privilege escalation.
6. Static analysis and audit: use automated tools and independent human review.
7. Deployment verification: verify source code, constructor parameters, roles, initial allocations, and configuration on the target network.

A useful supply invariant for a basic ERC-20 is:

The invariant assumes that all balance-changing paths are included, that balances are interpreted in base units, and that no external accounting mechanism is being omitted. Burn and mint operations must update both balances and total supply consistently.

9. Responsible Token Issuance

Responsible issuance begins before deployment. The issuer should identify the purpose of the token, affected stakeholders, jurisdictions, consumer risks, and governance structure. Legal classification differs across jurisdictions and may depend on facts such as marketing, economic rights, managerial efforts, redemption promises, and purchaser expectations. Technical teams should obtain qualified legal advice rather than assuming that decentralisation eliminates regulation.

Good practice includes:

• publishing clear supply, allocation, vesting, and authority information;
• disclosing minting, pausing, blacklisting, upgrade, and confiscation powers;
• avoiding misleading claims about price, returns, scarcity, or decentralisation;
• protecting personal data and avoiding unnecessary on-chain disclosure;
• documenting incident response and recovery procedures;
• using multisignature control for treasury and privileged roles;
• separating deployment, administration, and user-facing systems;
• providing accessible risk disclosures and support channels.

Governance should be proportionate. An immutable contract reduces some forms of administrative abuse but can make genuine defects impossible to correct. An upgradeable contract allows maintenance but introduces upgrade authority, proxy, and storage-layout risks. The choice should be explicit and subject to time locks, role separation, monitoring, and transparent change procedures.

10. Applied Case: Illustrative Event-Ticket Platform

Background

Consider an illustrative platform called OpenVenue. It issues event tickets and collectible attendance badges. Tickets exist in several classes—standard, premium, and backstage—with many units per class. Badges are unique and may be claimed after attendance.

Problem

The original design used a separate ERC-721 contract for every ticket class. This created unnecessary deployment and management overhead, while the marketplace needed a standard way to display metadata and calculate creator royalties. The platform also wanted users to pay with a sponsored approval transaction.

Analysis

Ticket classes are repeated asset types, so ERC-1155 is more suitable than separate ERC-721 contracts. Attendance badges are individually identifiable, so ERC-721 is appropriate. Metadata must distinguish event, venue, class, seat or admission rights, and validity. The platform must also prevent double redemption and define whether a transferred ticket remains valid.

Approach and Solution

OpenVenue uses ERC-1155 for tickets and ERC-721 for badges. The ticket contract records redemption status and applies role-based minting. Metadata is stored using content-addressed URIs, while any mutable event information is clearly labelled. ERC-2981 communicates a royalty recommendation for secondary sales. EIP-2612 is used for the payment token, not assumed to exist for every token. A relayer verifies deadlines and pays gas only after validating the signed permit.

The platform documents that ERC-2981 does not force every marketplace to pay royalties. It uses a multisignature treasury, a timelocked administrative role, and monitoring for unusual minting or transfer activity. Tests cover batch transfers, receiver callbacks, duplicate redemption, expired permits, nonce reuse, and unauthorised minting.

Outcome

The design reduces contract duplication, improves inventory management, and makes the rights model clearer. It does not eliminate all risks: ticket validity remains a policy issue, metadata availability must be monitored, and marketplaces may differ in royalty support.

Learning Points

The correct standard depends on the asset and operational model. Metadata and royalties are integration concerns as well as coding concerns. Signature-based approvals improve user experience but introduce replay and domain-separation requirements. Most importantly, technical compliance must be evaluated alongside governance and consumer protection.

11. Challenges and Contemporary Developments

Standards evolve through implementation experience. Common challenges include inconsistent marketplace support, non-standard extensions, gas costs, chain migration, bridge security, metadata disappearance, and ambiguous administrative powers. Layer-2 networks can reduce transaction costs but require careful treatment of chain identifiers, messaging, finality, and user expectations.

Account abstraction and smart-contract wallets may change assumptions that an account is an externally owned address capable of producing an ordinary ECDSA signature. Permit systems and authentication flows should therefore support appropriate wallet standards and avoid rejecting legitimate contract accounts without justification.

Artificial intelligence can assist with code search, test generation, anomaly detection, and documentation review. It cannot replace cryptographic reasoning, economic analysis, legal review, or independent security assessment. AI-generated token contracts require the same scrutiny as any other code, including tests for hidden privileged functions, incorrect units, unsafe external calls, and misleading documentation.

Best-Practice Checklist

Before issuing a token, confirm that:

• the selected standard matches the asset model;
• required functions and events are implemented correctly;
• metadata has a documented permanence and update policy;
• royalties are described as recommendations unless technically enforced;
• permits use nonces, deadlines, correct domains, and secure signature validation;
• minting and burning obey explicit supply rules;
• allocations and vesting are publicly documented;
• privileged roles are minimised, separated, monitored, and protected;
• tests include adversarial and integration cases;
• users receive clear disclosures about risks and administrative powers;
• legal, tax, privacy, and consumer-protection issues have been reviewed.

Chapter Summary

ERC-20 provides a widely used interface for fungible balances, allowances, transfers, and supply operations. ERC-721 represents individually identifiable assets, while ERC-1155 efficiently represents multiple fungible, non-fungible, and semi-fungible asset classes. Metadata determines how tokens are described and discovered, but its permanence and update authority must be evaluated. ERC-2981 communicates royalty information without guaranteeing payment. EIP-2612 enables signature-based approvals but requires secure nonces, deadlines, domain separation, and replay protection.

Tokenomics links supply, allocation, vesting, utility, incentives, and governance. Interface compliance is only one part of quality: semantic behaviour, security, integration, legal compliance, and responsible communication are equally important. A sound issuance process combines standard libraries, testing, auditing, transparent authority, proportionate governance, and protection of users and affected communities.

Key Terms

ERC-20: Standard interface for fungible tokens.

ERC-721: Standard interface for non-fungible tokens.

ERC-1155: Multi-token standard supporting multiple asset types in one contract.

ERC-2981: Royalty-information standard for NFT-style assets.

EIP-2612: Permit extension enabling signature-based token approvals.

Fungible: Interchangeable and equivalent in units of the same class.

Non-fungible: Individually identifiable and not inherently interchangeable.

Metadata: Descriptive information associated with a token.

Token URI: Location or reference for token metadata.

Allowance: Amount a spender is authorised to transfer for an owner.

Permit: Signed authorisation that can establish an allowance.

Nonce: Number used to prevent replay of a signed operation.

Basis point: One hundredth of one percentage point; 10,000 basis points equal 100%.

Circulating supply: Tokens considered available in the market under a stated definition.

Vesting: Controlled release of tokens over time or on specified conditions.

Fully diluted supply: Supply assuming all planned or authorised tokens are issued.

Interface compliance: Conformance to specified function and event signatures.

Semantic compliance: Conformance to the expected meaning and behaviour of an interface.

Multisignature wallet: Wallet requiring approvals from multiple authorised signers.

Content-addressed storage: Storage where retrieval is linked to content identity, commonly through a cryptographic hash.

Review Questions

Short Answer Questions

1. What is the difference between fungible and non-fungible tokens?
2. Why is the ERC-2981 standard not a guarantee that royalties will be paid?
3. What security purpose does a nonce serve in a permit system?
4. Why must token amounts normally be represented as integers in Solidity?
5. State two reasons why ERC-1155 may be preferable to multiple ERC-721 contracts.

Long Answer Questions

1. Compare ERC-20, ERC-721, and ERC-1155 in terms of asset identity, transfer operations, metadata, and suitable applications.
2. Explain the principal security and usability considerations when implementing EIP-2612 permits.
3. Discuss how metadata permanence, update authority, and content addressing affect token-holder expectations.
4. Explain why interface compliance, semantic compliance, and security quality should be evaluated separately.
5. Develop a responsible token-issuance framework covering tokenomics, governance, disclosure, testing, and legal review.

Analytical / Application Questions

1. A platform issues 1,000,000 tokens, allocates 20% to a team, 15% to investors, 25% to community incentives, and 10% to a treasury. What percentage remains for other categories, and what additional information is needed before calling the allocation complete?
2. A marketplace reports a sale price of 3 ETH and a royalty rate of 500 basis points. Calculate the royalty in ETH using the standard basis-point relationship, and explain why the marketplace may still not pay it.
3. Design a standard-selection and security-testing plan for a game containing coins, repeatable weapons, unique characters, and batch inventory transfers. Justify each selected token standard and identify at least four tests.

Multiple Choice Questions with Answers

Question 1

Which standard is primarily designed for fungible tokens?

A. ERC-20

B. ERC-721

C. ERC-1155

D. ERC-2981

Correct Answer: A. ERC-20

Question 2

What does the ERC-721 token identifier distinguish?

A. Only the wallet’s private key

B. An individually identifiable token within a contract

C. The blockchain’s consensus algorithm

D. The royalty percentage of every marketplace

Correct Answer: B. An individually identifiable token within a contract

Question 3

What is the principal purpose of ERC-2981?

A. To enforce token burning

B. To provide batch transfer functions

C. To communicate royalty information

D. To create private keys

Correct Answer: C. To communicate royalty information

Question 4

In a permit system, which mechanism primarily prevents reuse of the same signed authorisation?

A. A metadata URI

B. A nonce

C. A royalty receiver

D. A token decimal value

Correct Answer: B. A nonce

Question 5

If a royalty rate is 500 basis points, what percentage does it represent?

A. 0.5%

B. 5%

C. 50%

D. 500%

Correct Answer: B. 5%

Question 6

Which standard is especially suitable for a contract containing many repeated asset types and batch transfers?

A. ERC-1155

B. ERC-2981

C. EIP-712 only

D. ERC-20 only

Correct Answer: A. ERC-1155

Question 7

What does the ERC-20 decimals value primarily represent?

A. The number of owners allowed to mint

B. A display convention for converting base units

C. The maximum token supply

D. The number of required multisignature approvals

Correct Answer: B. A display convention for converting base units

Question 8

Which statement about ERC-2981 is correct?

A. It guarantees that every marketplace transfers royalties

B. It communicates royalty information but does not itself force payment

C. It replaces ownership functions in ERC-721

D. It prevents all secondary-market transfers

Correct Answer: B. It communicates royalty information but does not itself force payment

Question 9

If maximum supply is C, current supply is S, and a mint amount is m, which condition represents a cap check?

A. S − m ≥ C

B. S + m ≤ C

C. C + m ≤ S

D. S × m = C

Correct Answer: B. S + m ≤ C

Question 10

Which practice best supports responsible token issuance?

A. Hiding privileged minting powers to simplify marketing

B. Requesting unlimited approvals whenever possible

C. Publishing supply, allocation, vesting, and administrative authority information

D. Treating an interface as proof that the token is legally compliant

Correct Answer: C. Publishing supply, allocation, vesting, and administrative authority information