Treat every CNFTP scenario as four separable claims: the token standard and its on-chain ownership record, the metadata and where the asset is stored, the rights that transferred with the sale, and the market forces shaping price. Label each claim first, answer the layer the question actually asks about, and never let an on-chain fact answer an off-chain question or vice versa.
Four Layers: Separating Token, Metadata, Rights, and Market Claims
Decompose every scenario into four layers — token standard, metadata and storage, rights, and market — before answering. Because all four layers describe the same token, a fact at one layer can look like the answer to a question at another layer.
The token layer covers the contract standard, token IDs, and the owner mapping that transfers change. The metadata layer covers the descriptive JSON, the asset it points to, and the storage backing it. The rights layer covers copyright and licenses, which live in legal documents rather than on-chain. The market layer covers listings, liquidity, trading volume, and pricing behavior. Your first move on any question is to write a one-line label for each claim it contains.
Layer blending is where the subject genuinely gets hard. Consider the phrase "the NFT is immutable": the ownership record is extremely difficult to alter without consensus rules, while the metadata may sit behind a mutable web URL that one company controls. Both statements describe the same token and both can be true at different layers. Take any NFT headline, write four one-line claims — one per layer — and check which the source actually supports; that habit transfers directly to layered scenario questions.
- Token layer: standard, token IDs, ownership and transfer rules
- Metadata layer: JSON fields, asset pointer, storage type
- Rights layer: copyright status, license grants, assignments
- Market layer: listings, floor prices, volume, liquidity
ERC-721 vs ERC-1155: Choosing a Standard for Editioned Collectibles
ERC-721 issues each token a unique ID with supply of one. ERC-1155 manages many token IDs in a single contract, each with its own supply, enabling semi-fungible editions and batch operations.
Worked scenario: a studio plans "Galaxy Cards" — 9,000 copies spread across five card designs, plus 100 one-of-one artworks, 9,100 items in total. The tempting mistake is minting all 9,100 items as ERC-721 because "collectible means 721." That choice records 9,000 near-duplicate tokens individually, makes batch distribution clumsy, and presents every copy to marketplaces as a distinct unique item. The better decision is ERC-1155 for the card editions — each design becomes one token ID with a supply count — and unique supply-one tokens for the one-of-ones.
Why it matters: the standard determines both cost structure and how scarcity reads to collectors. An edition of 1,800 under one token ID is legible as an edition; 1,800 separate ERC-721 tokens are not. When you compare the two standards on paper, always ask what the scenario is really selling — a unique object, a counted edition, or a mixed catalog — and match the accounting model to that answer rather than to the word "NFT."
| Dimension | ERC-721 | ERC-1155 |
|---|---|---|
| Ownership unit | One unique token ID, supply of one | Many token IDs, each with its own supply |
| Fungibility within the contract | Every token distinct | Semi-fungible: copies of one ID are interchangeable |
| Batch operations | Not native to the standard | Native batch transfers and batch balances |
| Natural fit | One-of-one art, identity tokens | Editioned collectibles, game items, mixed catalogs |
| Display caveat | Universally read as a unique asset | Marketplaces may show editions differently by token ID |
Why an On-Chain Token Does Not Guarantee On-Chain Art
The ownership record lives on-chain; the artwork and its JSON metadata usually do not. Tracing the tokenURI shows whether it points to content-addressed storage like IPFS or to a mutable web server.
Trace the path: a token typically exposes a tokenURI, which resolves to a JSON document with fields such as name, description, image, and attributes. If that URI is an IPFS content identifier, the address is derived from the content itself — identical content yields the same address, and any change produces a different one. If it is an https URL on a company server, the company controls what every token displays. Mini-scenario: a gallery hosts metadata at api.example.com/metadata/1; the API shuts down and the image vanishes while the owner record persists.
The mutability distinction is genuinely confusing because both layers sound permanent. A contract can expose a setBaseURI function, letting an authorized address repoint every token's metadata without touching the on-chain ownership record at all. Your self-check on any example: note whether the URI is a content hash or a domain name, and who holds update authority. A content-addressed URI removes the silent-rewrite path for the file, though pinning — someone continuing to host the content — remains a separate, practical consideration.
Token Ownership Is Not Copyright: Reading the License Before the Purchase
A token transfer updates the on-chain owner mapping; it does not by itself transfer copyright. Rights move through licenses or assignments in off-chain documents, which may or may not accompany the sale.
Separate three things: the token (a record of ownership of that token), the underlying work (which carries copyright), and the license (the document saying what a holder may do). As a general principle, the creator retains copyright unless it is explicitly assigned, and the specific rules vary by jurisdiction — treat study scenarios as concept questions about this separation, not as legal advice for real transactions. Some projects grant holders broad commercial licenses in their terms; others grant display rights only, and the difference is invisible on the blockchain.
Worked scenario: a beverage brand buys a one-of-one NFT from an independent artist and plans to print the artwork on cans and merchandise. The plausible mistake is assuming purchase equals commercial rights and launching the product line. The better decision: before acquisition, locate the project's license terms or ask for a written assignment; if neither grants commercial use, negotiate one. Why it matters — the brand would face an infringement claim regardless of holding the token, because the right they needed was never conveyed by the transfer.
Royalty Signals vs. Royalty Enforcement in Transfer Logic
Royalty standards such as EIP-2981 let a contract report a recipient and percentage, but reporting is not enforcement. Classify each scenario's mechanism as signaling, marketplace policy, or enforced contract logic.
EIP-2981 defines a standard function a contract can implement so that marketplaces can query royalty information — a recipient address and a basis-point amount. Implementing it announces intent; honoring the signal has historically been each marketplace's policy decision. Enforcement by code is a different design: some contracts embed a split directly into their transfer or sale functions so the creator's share moves with every trade. A scenario saying "the creator earns royalties on resale" is incomplete until you identify which of the three mechanisms is doing the work.
Valuation claims need the same discipline. Distinguish the floor price — the lowest active listing — from the last realized sale price, and treat trading volume as a signal to interrogate rather than proof of demand, since round-trip trades between related wallets can inflate it. Practice with paper examples: given a collection with a low floor, high volume, and one dominant wallet pair, describe what each number measures and what it fails to establish before reaching any conclusion about value.
Mint Functions, Approvals, and Mutable URIs: Contract Risk on Paper
Analyze contracts read-only: check who can mint, whether metadata URIs are mutable, what approvals grant, and what custom transfer logic adds. For enterprise designs, decide custody, chain, and data mapping explicitly.
Build a paper checklist for any contract you study: Does minting require the owner (an onlyOwner-style guard) or is it public, and is there a supply cap? Does a setBaseURI or equivalent exist, and who may call it? Can the contract be paused or blacklist addresses? What do approval functions grant — setApprovalForAll hands another address control over all your tokens of that contract, which is why unsolicited approval requests are a standard warning. Each item is answerable by reading, not by transacting.
Enterprise integration questions reward the same explicitness. Before naming tools, decide the custody model — a custodial service holding keys for users versus self-custody infrastructure — because it drives compliance, recovery, and user-experience choices. Decide the chain based on where the intended users and costs sit, and map enterprise records to token IDs deliberately: which field is the token ID, which data stays in the metadata JSON, and which stays in existing company systems reached through APIs. A two-paragraph design sketch covering those four decisions is a reusable study artifact.
- Mint authority: owner-restricted or public, capped or uncapped
- Metadata authority: setBaseURI present, and who controls it
- Approval scope: per-token approvals vs. setApprovalForAll
- Custom logic: pauses, blacklists, fees, and withdrawal paths
A Trace-First Preparation Sequence with a Self-Check Rubric
Work four phases: define the token standards from scratch, trace one live token read-only, write and resolve your own two-layer conflict scenarios, then read one verified contract's function list. Score against the rubric below.
Phase 1: write your own one-sentence definitions of ERC-721, ERC-1155, tokenURI, and content addressing, then contrast each pair — definitions you phrased yourself expose gaps faster than re-reading. Phase 2: open a block explorer in read-only mode, pick one well-known collection, find a tokenURI, follow it, and record whether it is a content identifier or a domain. Administrative details such as enrollment and exam delivery belong to the issuer; check there for current logistics.
Phase 3: write five scenarios that deliberately conflict two layers — a sale plus a rights question, a listing plus a metadata question — and resolve them. Phase 4: read the function list of one verified contract and classify each function against the risk checklist above. Then score the trace exercise: 0–2 per layer, where 2 means you stated the claim, named the mechanism, and noted its limit, unprompted. A milestone of 7 of 8 is a learning target, not a prediction of any exam result.
- Rubric 0–2 per layer: claim stated, mechanism named, limit noted — milestone 7/8 is a learning target, not a pass prediction
- Readiness check: explain the ERC-721 vs ERC-1155 decision from a fresh scenario
- Readiness check: trace a tokenURI to its storage type without notes
- Readiness check: separate token ownership from copyright with the jurisdiction caveat
- Readiness check: classify three royalty descriptions by mechanism
- Readiness check: list three mutable-metadata risk flags from memory
References and further reading
Use these references to explore the concepts and check the latest information from the relevant organizations.