Ethereum Standards and Digital Assets

Introduction and Context

Ethereum standards are shared interfaces and behavioural conventions that allow independently developed applications, wallets, exchanges, marketplaces and analytics systems to interact with digital assets. A token standard does not itself create economic value. Rather, it defines how ownership, transfer, approval, metadata and related functions are represented on-chain.

The most important standards in this chapter are ERC-20 for fungible tokens, ERC-721 for non-fungible tokens, and ERC-1155 for multi-token contracts. Extensions such as ERC-2981 royalties, ERC-4907 rentable NFTs, EIP-712 typed-data signatures and attestation schemes expand the usefulness of these basic models. Their use introduces technical, economic, legal and ethical responsibilities.

Learning Objectives

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

1. Distinguish fungible, non-fungible and multi-token assets.
2. Explain the interfaces and security assumptions of ERC-20, ERC-721 and ERC-1155.
3. Implement and test basic token contracts using Solidity.
4. Design metadata, approvals, royalties and token-economic mechanisms responsibly.
5. Evaluate identity and attestation applications without confusing blockchain records with legal identity.
6. Identify security, governance, regulatory and ethical risks in digital-asset systems.

1. Digital-Asset Models

A digital asset is a programmable representation of a right, unit, item, credential or claim. The blockchain normally records ownership and permitted state transitions; it may not contain the underlying media, legal document or physical object.

Fungible assets

Fungible units are interchangeable. One unit has the same operational properties as another unit of the same class. Currency-like tokens, governance tokens and points commonly use ERC-20. Balances are represented by account addresses and integer amounts. ERC-20 amounts have no inherent decimal meaning: the contract stores the smallest indivisible units, while decimals() provides a display convention.

If a token displays d decimal places, a displayed quantity q corresponds to:

where u is the integer number of base units. This conversion assumes that q is represented accurately; software should avoid binary floating-point arithmetic for token amounts.

Non-fungible assets

An NFT identifies an individual token by a tokenId. Two token IDs may have different owners, metadata, rights or histories. ERC-721 is suitable for unique works, memberships, certificates and individually tracked assets. Non-fungibility does not automatically prove authenticity, scarcity or ownership of copyright.

Multi-token assets

ERC-1155 allows one contract to manage many token IDs. Each ID may represent a fungible currency, a semi-fungible edition, or a unique item. A game can therefore use one contract for gold, weapon editions and individual characters. Batch transfers reduce transaction overhead compared with separate transfers, although gas use still depends on the number of IDs and recipients.

2. ERC-20: Fungible Token Standard

The ERC-20 interface specifies functions including totalSupply(), balanceOf(), transfer(), allowance(), approve() and transferFrom(), together with Transfer and Approval events. Modern implementations also commonly expose name(), symbol() and decimals(), although these metadata functions are not the core transfer mechanism.

A simplified Solidity illustration is:

interface IERC20 {
    function totalSupply() external view returns (uint256);
    function balanceOf(address account) external view returns (uint256);
    function transfer(address to, uint256 amount) external returns (bool);
    function allowance(address owner, address spender) external view returns (uint256);
    function approve(address spender, uint256 amount) external returns (bool);
    function transferFrom(address from, address to, uint256 amount)
        external returns (bool);

    event Transfer(address indexed from, address indexed to, uint256 value);
    event Approval(address indexed owner, address indexed spender, uint256 value);
}

The interface does not prescribe who may mint or burn tokens. Those policies are implementation choices and should be explicit. A fixed-supply token may mint once during deployment. A stable-value token may mint and burn under controlled reserve or collateral rules. A governance token may use a capped issuance schedule.

Allowances and approval risk

An allowance authorises a spender to call transferFrom() up to a specified amount. It is not ownership transfer by itself. A common user-interface risk occurs when a user grants an effectively unlimited allowance to a contract that is later compromised. Another issue is the allowance-update race: changing a non-zero allowance directly to another non-zero allowance can allow a spender to use the old allowance before the new transaction is confirmed. A safer workflow is to set the allowance to zero before setting a new value, or use a well-audited increase/decrease allowance pattern.

Contracts interacting with ERC-20 tokens should not assume that every token behaves identically. Some older or non-standard tokens return no Boolean value, while others impose transfer fees or rebasing behaviour. Audited wrappers and safe-transfer libraries help, but they do not eliminate economic or administrative risk.

Supply accounting

For a conventional token, supply accounting is conceptually:

S_t is total supply at time t, M_t is newly minted supply, and B_t is burned supply. The formula assumes that all minting and burning events are correctly recorded and that transfers merely redistribute existing units. It does not describe rebasing tokens without additional terms.

3. ERC-721: Unique Tokens

ERC-721 defines ownership and transfer of individually identified assets. Important functions include ownerOf(tokenId), balanceOf(owner), safeTransferFrom(), transferFrom(), approve(), getApproved(), setApprovalForAll() and isApprovedForAll(). Events include Transfer, Approval and ApprovalForAll.

safeTransferFrom() is important when the recipient is a contract. The receiving contract should implement onERC721Received() and return the expected selector. This prevents tokens from being sent accidentally to contracts that cannot manage them. transferFrom() can be appropriate when the caller has independently verified the recipient, but it provides less protection against incompatible contract recipients.

An ERC-721 token may expose metadata through tokenURI(tokenId). The URI can identify JSON stored on-chain, in content-addressed storage such as IPFS, or on a conventional server. Each choice creates different availability, mutability and governance consequences.

Approval models

ERC-721 has two main approval patterns:

• A single-token approval authorises an address to transfer one token.
• Operator approval authorises an address to manage all tokens owned by an account in that collection.

Operator approvals are convenient for marketplaces but powerful. Users should revoke them when no longer needed. Contracts should emit correct events and ensure that approvals are cleared or updated appropriately when ownership changes.

4. ERC-1155: Multi-Token Architecture

ERC-1155 represents balances using a pair such as (owner, id). Its core functions include balanceOf(), balanceOfBatch(), setApprovalForAll(), safeTransferFrom() and safeBatchTransferFrom(). Transfer events include TransferSingle and TransferBatch.

An ERC-1155 token ID may be:

• fungible, where many units exist;
• semi-fungible, where an edition has a limited quantity; or
• effectively non-fungible, where the maximum supply is one.

This flexibility is useful, but the meaning of each ID must be documented. A token ID of one in one contract has no universal relationship to token ID one in another contract. Receiving contracts should implement onERC1155Received() or onERC1155BatchReceived() when applicable.

Batch operations improve usability, but they increase implementation complexity. Developers must check array lengths, avoid inconsistent IDs and amounts, and consider gas limits for large batches.

Comparison of principal standards

5. Metadata and Provenance

Metadata connects an on-chain identifier to descriptive information such as name, image, attributes, creator and licensing terms. A typical NFT JSON document might contain:

{
  "name": "Workshop Certificate #42",
  "description": "Completion certificate",
  "image": "ipfs://bafy...",
  "attributes": [
    {"trait_type": "Level", "value": "Diploma"}
  ]
}

The token contract may construct a URI from a base URI and token ID, return a fully stored URI, or return on-chain JSON encoded as a data URI. On-chain metadata can improve persistence but may increase deployment or update costs. Off-chain metadata is cheaper but depends on storage availability and governance.

A content identifier can demonstrate that retrieved content matches a referenced object, but it does not guarantee that the content will remain hosted, that the creator had rights to publish it, or that the description is truthful. Responsible systems document whether metadata is immutable, who can update it, how updates are announced, and what happens if a storage provider disappears.

6. Extensions: Royalties, Rentals and Signatures

ERC-2981 royalties

ERC-2981 provides a standard way to query royalty information for a sale. It does not force marketplaces to pay royalties and does not define the sale price or payment settlement. The royalty amount is commonly calculated as:

R is the royalty amount, P is the sale price in the payment currency, r is the royalty numerator, and D is the denominator selected by the contract. The calculation assumes that P, r and D are expressed consistently and that integer division and rounding are handled safely. A contract should ensure that r ≤ D unless a different policy is deliberately specified.

Royalties are therefore best described as discoverable payment terms, not guaranteed perpetual income. Marketplace enforcement, user expectations and applicable law remain relevant.

ERC-4907 and temporary use

Rental-oriented extensions separate an NFT owner from a temporary user and may include an expiry time. This is useful for game assets, subscriptions and access passes. A consuming application must verify expiry and decide what actions a user may perform. It must not assume that every NFT supports the same rental semantics.

EIP-712 typed data

EIP-712 defines a structured method for signing typed data. It improves human-readable signing and domain separation compared with signing an opaque byte string. A domain normally includes a name, version, chain ID and verifying contract. Applications must still prevent replay across chains, contracts, sessions or nonce values. A signature is authorisation for a specified message; it is not proof that the signer has agreed to unrelated terms.

7. Identity and Attestations

An identity system can associate an address with claims such as “completed course,” “passed a compliance check” or “controls an organisation domain.” An attestation is a signed statement by an issuer about a subject. It may be stored on-chain, referenced by a hash, or held off-chain with an on-chain proof.

A useful conceptual model has four roles:

1. Issuer creates or signs the claim.
2. Subject is the person, organisation or address described.
3. Verifier evaluates whether the claim satisfies a requirement.
4. Registry or protocol records status, revocation and schema information.

An address is not automatically a real-world identity. Linking an address to a person requires an identity process, and that process introduces privacy, security and legal obligations. Attestations should be purpose-limited, minimally disclosed and revocable where appropriate. Personal data should not be placed on a public immutable ledger merely because the technology permits it.

Soulbound or non-transferable credentials can prevent trading, but non-transferability alone does not make a credential accurate or fair. A system needs issuer governance, correction procedures, expiry rules and protection against coercive disclosure.

8. Token Economics and Responsible Design

Token economics concerns supply, distribution, incentives, utility, governance and value flows. A design should answer:

• Why is a token necessary rather than a database entry or conventional payment method?
• Who receives initial supply and under what vesting conditions?
• Can administrators mint, pause, blacklist or upgrade the contract?
• What prevents concentration, manipulation or wash trading?
• What rights, if any, does the token represent?
• How are users protected from misleading claims?

For a fixed-supply token, the maximum supply is a protocol constraint. For an inflationary token, issuance should be transparent. A simple annualised issuance rate can be expressed as:

I is the issuance rate for a stated period, M is tokens minted during that period, and S_0 is supply at the start of that period. This measure is meaningful only when the period and supply basis are stated. If supply changes substantially during the period, analysts should report the time basis or use an explicitly defined average supply.

Token price is not utility. A token can have useful access rights and still have volatile market value. Conversely, a high market price does not prove sustainable demand. Treasury management, liquidity provision and incentives can create conflicts of interest and should be governed transparently.

9. Implementation and Security Practices

A professional implementation should begin with a written specification: asset meaning, supply rules, permitted actors, metadata policy, approval behaviour, upgrade authority, pause policy and event requirements. Developers should prefer well-reviewed libraries and avoid rewriting standard primitives without a clear reason.

Important controls include:

• checks-effects-interactions and reentrancy protection where external calls occur;
• explicit access control for minting, burning, pausing and upgrades;
• safe receiver checks for ERC-721 and ERC-1155;
• protection against arbitrary token URI mutation;
• correct handling of zero addresses and token IDs;
• event emission that accurately reflects state changes;
• tests for unauthorized transfers, approval revocation, batch length mismatch and malicious receivers;
• static analysis, fuzz testing and independent review before deployment.

Upgradeable contracts require special care. An upgrade administrator can change token behaviour, metadata or supply rules. Proxy storage layouts must remain compatible, and users should be told who controls upgrades and whether a timelock or multisignature process exists.

Applied Case: Illustrative University Credential System

Background

A fictional university wants to issue course-completion credentials that employers can verify without contacting the registry for every application.

Problem

A publicly tradable certificate could encourage fraud, expose student information and create confusion between completion of a course and professional licensing. The university also needs to correct records when an administrative error occurs.

Analysis

An ERC-721 token could represent each credential, but transferability would undermine the meaning of a personal achievement. A non-transferable credential or an attestation is more appropriate. The credential should contain only a pseudonymous subject reference and a schema identifier. Sensitive information should remain off-chain.

Approach and solution

The university issues a signed attestation containing the course schema, subject identifier, issue date, issuer identifier and expiry or revocation reference. A verifier checks the issuer’s recognised key, the signature, the schema and revocation status. The system uses typed data with a domain separator and nonce to reduce replay risk. A public registry stores hashes and status rather than names, grades or identity documents.

If an error is identified, the issuer revokes the original attestation and issues a corrected one. Governance rules define who may issue, revoke or delegate authority. Students receive an explanation of what is public and how their credential can be verified.

Outcome

The design provides verifiable claims while limiting unnecessary disclosure. It does not claim that the blockchain independently proves attendance, identity or academic quality; those claims depend on university governance and verification procedures.

Learning points

The correct standard follows the asset’s meaning. A transferable NFT is not automatically an appropriate credential. Privacy, revocation and issuer accountability are central design requirements, not optional additions.

Challenges, Regulation and Ethics

Digital assets can be used for speculation, fraud, unauthorised fundraising, money laundering and deceptive marketing. Classification under securities, consumer-protection, tax, payments, intellectual-property and data-protection law varies by jurisdiction and depends on facts, not merely on the label “utility token” or “NFT.” Organisations should obtain qualified legal advice before launch.

Public ledgers create privacy challenges because transaction histories are persistent and easily correlated. Wallet loss, phishing, malicious approvals and counterfeit collections can cause irreversible harm. User interfaces should display the chain, contract address, approval scope and signing message clearly.

Environmental impact depends on the network’s consensus and infrastructure, but energy claims should be evidence-based rather than assumed from the word “blockchain.” Accessibility also matters: high transaction costs, wallet complexity and lack of recovery mechanisms can exclude users.

Contemporary Developments and Best Practices

Current practice increasingly combines token standards with account abstraction, signature-based approvals, layer-two networks, content-addressed storage, verifiable credentials and automated monitoring. These developments improve usability but introduce new trust assumptions. A layer-two bridge, relayer, sequencer or storage provider may become a critical dependency.

A responsible deployment should:

1. choose the simplest standard that expresses the business requirement;
2. publish contract addresses, source code and administrative powers;
3. use test networks and staged releases;
4. disclose supply, allocation, vesting and upgrade rules;
5. minimise personal data and provide revocation or correction mechanisms;
6. monitor approvals, transfers, minting and unusual administrative actions;
7. design for users who lose keys or need accessible recovery;
8. conduct technical, legal, economic and ethical review before launch.

Chapter Summary

ERC-20 represents interchangeable units through balances and allowances. ERC-721 represents individually identified tokens with ownership, approvals and metadata. ERC-1155 manages many token IDs and supports efficient batch operations. Extensions such as ERC-2981, ERC-4907 and EIP-712 add royalty discovery, temporary use and structured signatures, but none removes the need for marketplace enforcement, replay protection or governance.

Metadata determines how an asset is described and located, while provenance and authenticity require broader evidence than a token record alone. Identity and attestation systems must distinguish addresses from real-world persons and should protect privacy, support revocation and identify accountable issuers. Token economics should make supply, incentives, authority and risks explicit. Secure implementation requires tested standards, careful approvals, access control, receiver checks and transparent upgrade policies. The most important professional principle is to select a standard according to the rights and responsibilities that the asset is intended to represent.

Key Terms

ERC-20: Standard interface for fungible Ethereum tokens.

ERC-721: Standard interface for individually unique tokens.

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

Fungible: Interchangeable with another unit of the same class.

Non-fungible: Individually identifiable and not operationally interchangeable.

Allowance: Amount an ERC-20 spender may transfer on behalf of an owner.

Operator: Address authorised to manage an owner’s approved NFT or multi-token assets.

Metadata: Descriptive information associated with a token.

Content identifier: Reference intended to identify particular digital content.

Minting: Creating new token units.

Burning: Permanently removing token units from circulation.

ERC-2981: Standard interface for querying royalty information.

Attestation: A signed or recorded claim made by an issuer about a subject.

Issuer: Entity that creates or signs an attestation.

Revocation: Process of invalidating a previously issued claim.

EIP-712: Standard for signing structured, typed messages.

Replay attack: Reuse of a valid authorisation in an unintended context.

Upgradeability: Ability to change contract logic after deployment.

Token economics: Study and design of supply, incentives, distribution and value flows.

Review Questions

5 Short Answer Questions

1. What is the principal difference between ERC-20 and ERC-721?
2. What purpose does an ERC-20 allowance serve?
3. Why is safeTransferFrom() useful for NFTs?
4. What does ERC-2981 provide, and what does it not guarantee?
5. Why should personal data generally not be stored directly on a public blockchain?

5 Long Answer Questions

1. Compare ERC-20, ERC-721 and ERC-1155 in terms of data model, applications, approvals and implementation risks.
2. Explain how metadata storage choices affect persistence, mutability, cost and user trust.
3. Discuss the security risks of token approvals and propose user-interface and contract-level mitigations.
4. Explain the roles of issuer, subject, verifier and registry in an attestation system.
5. Evaluate the governance and ethical risks of an upgradeable token with minting and pausing powers.

3 Analytical / Application Questions

1. A game needs gold units, ten thousand identical swords and one individually tracked tournament trophy. Recommend a token architecture and justify the choice.
2. Design a credential system for a professional training provider. Specify the token or attestation model, metadata policy, revocation process and privacy controls.
3. A marketplace advertises “perpetual royalties” using ERC-2981. Analyse what the standard actually guarantees and identify additional technical, commercial and legal mechanisms needed to support the claim.

Multiple Choice Questions with Answers

Question 1

Which standard is primarily designed for interchangeable token units?

A. ERC-20

B. ERC-721

C. ERC-1155 only for unique assets

D. ERC-2981

Correct Answer: A. ERC-20

Question 2

What does an ERC-20 allowance authorise?

A. A spender to transfer up to a specified amount for an owner

B. Anyone to mint tokens

C. A buyer to change token metadata

D. A marketplace to reverse any transfer

Correct Answer: A. A spender to transfer up to a specified amount for an owner

Question 3

What is a principal advantage of ERC-1155?

A. It guarantees that all tokens are non-transferable

B. It manages multiple token IDs and supports batch transfers

C. It removes the need for access control

D. It automatically pays royalties

Correct Answer: B. It manages multiple token IDs and supports batch transfers

Question 4

What is the main purpose of an ERC-721 safe transfer to a contract?

A. To ensure the recipient contract can acknowledge receipt

B. To convert the NFT into ERC-20 units

C. To hide the token ID from observers

D. To make the token permanently non-transferable

Correct Answer: A. To ensure the recipient contract can acknowledge receipt

Question 5

If a token displays 2 decimal places, how many base units represent a displayed quantity of 7.25?

A. 7.25

B. 72.5

C. 725

D. 7,250

Correct Answer: C. 725

Question 6

What does ERC-2981 primarily standardise?

A. A query for royalty information

B. Mandatory marketplace royalty payment

C. NFT lending collateral ratios

D. Identity verification of creators

Correct Answer: A. A query for royalty information

Question 7

Which statement about an Ethereum address is correct?

A. It automatically proves the holder’s legal identity

B. It is always controlled by a university or company

C. It is an on-chain identifier whose real-world linkage requires additional evidence

D. It cannot sign attestations

Correct Answer: C. It is an on-chain identifier whose real-world linkage requires additional evidence

Question 8

Which practice helps reduce signature replay across contracts or chains?

A. Removing the chain ID from signed data

B. Using domain separation, nonces and an intended verifying contract

C. Signing arbitrary opaque messages only

D. Allowing every signature to be reused indefinitely

Correct Answer: B. Using domain separation, nonces and an intended verifying contract

Question 9

For the supply equation Sₜ₊₁ = Sₜ + Mₜ − Bₜ, what does Bₜ represent?

A. Balances transferred

B. Base-unit precision

C. Tokens burned during the period

D. Tokens approved by a spender

Correct Answer: C. Tokens burned during the period

Question 10

Which is the most responsible approach for a personal educational credential?

A. Store all identity documents permanently on-chain

B. Make the credential freely tradable without restrictions

C. Use privacy-conscious claims with issuer accountability and revocation

D. Assume the blockchain independently proves attendance

Correct Answer: C. Use privacy-conscious claims with issuer accountability and revocation