中文版 · Blockchain learning guide · Previous article
Blockchain learning · Article BC073
A unique token record can identify an address, a token number and a metadata reference. That does not make the referenced image, its continued availability and permission to use it the same thing. To understand an NFT-related claim, trace each connection rather than treating the screen as one indivisible asset.
The practical method is to ask four questions in order: Which record? Which content? Available when and through which evidence? Permitted for which use? A clear answer to one question can coexist with an unresolved answer to another.
This lesson follows a fictional classroom image through a record, a metadata document and a permission card. It is an evidence-reading exercise, not an NFT purchase guide or an assessment of anyone’s legal rights. The programme rules are invented. Actual licensing and legal questions depend on the relevant documents, parties and applicable law.
Choose your reading route
In this guide
- 1. One screen can combine several separate records
- 2. What the technical standards contribute
- 3. The fictional classroom packet
- 4. Case A: the on-chain reference changes
- 5. Case B: the reference stays, but the returned bytes change
- 6. Case C: the image cannot be retrieved
- 7. Case D: content verification succeeds, but authority is unknown
- 8. Cases E and F: a broader claim and a later holder
- 9. Write a version-specific evidence report
- 10. Keep the jurisdiction boundary visible
- 11. Exercises with answers
- 12. Frequently asked questions
- 13. Sources and further reading
- Read sections 1–3 to separate the evidence layers and understand the fictional packet.
- Work through sections 4–8 to see how changing one layer changes the conclusion.
- Use sections 9–10 to write a version-specific report and assess a displayed claim.
- Finish with the exercises and FAQ if you want to test whether you are keeping the connections straight.
Back to contents · Next section
1. One screen can combine several separate records
An NFT interface may show a picture, a collection name, a holder address and a description. A reader can easily assume that all four came from the same place, were verified in the same way and will change together. The underlying evidence may be much more fragmented.
For example, a chain observation can identify a token and return an address. A metadata query can return a reference. Retrieving that reference can produce a document, which may contain another reference to an image. A separate statement may claim that the holder can display, reproduce or otherwise use the image.
Each connection needs its own explanation. Where did the document come from? Which version was retrieved? What binds the image to the document? Who made the permission statement, and what exact use does it cover?
A successful record lookup does not answer all those questions. Nor does a broken image necessarily show that the chain record disappeared. Keeping the layers separate makes it possible to describe partial success accurately instead of declaring everything either genuine or broken.
Back to contents · Next section
2. What the technical standards contribute
ERC-721 provides a useful technical starting point: it tracks distinguishable token identifiers within an identified contract. Its optional metadata extension includes tokenURI, which may point to a JSON document; the described metadata schema includes an image reference.
That interface does not, by itself, supply this lesson’s external permission rules. Nor does an optional metadata method imply that every token stores its image directly in the chain. A reader must inspect the actual representation rather than infer it from the standard’s name.
Content addressing can strengthen a different connection. The IPFS CID documentation explains identifiers that incorporate cryptographic and encoding information. Verification must follow the relevant representation: a CID is not universally the same as a plain hash of a whole downloaded file.
Retention is another question. The IPFS pinning documentation describes keeping data from garbage collection at a node and distinguishes local from remote pinning. Such mechanisms concern data retention; the mere presence of a content identifier does not supply a perpetual service commitment.
These technical references help identify the questions to ask. They do not replace evidence about the actual record, content, storage arrangement or permission in a particular case.
Back to contents · Next section
3. The fictional classroom packet
Assume network C, contract N and token ID 42. At identified accepted block B100, reliable supplied observations show H as the address in the token’s owner field. For this exercise, chain validation and observation accuracy are given; we are not deriving those properties from a screenshot.
At B100, the metadata query returns reference U1. A documented retrieval at time T1 obtains metadata document M1 from U1. M1 names image file F1 through an ordinary web reference, and a documented retrieval obtains F1’s bytes. U1 and F1 are labels, not real links.
A separate programme permission card, L1, has also been supplied. Within this invented programme, its authority, authenticity and applicability to this particular F1 are stipulated. L1 allows H to display F1 in a classroom. It does not supply permission for commercial merchandising, and no other grant is included in the packet.
Treat those statements as the complete baseline. We have a token relationship, a retrieved metadata version, a retrieved image and a narrowly defined programme permission. We have not supplied perpetual hosting, a rule transferring permission to a later holder, or a general right to use the image for every purpose.
The baseline conclusion is therefore specific: the supplied chain state identifies H for N/42 at B100; the recorded retrieval produced M1 and F1; and the invented programme allows H’s classroom display under L1. Calling this simply “H owns the picture” would discard several important distinctions.
All following cases are independent variations of this baseline unless expressly stated otherwise. Do not carry a change from one case into another.
Back to contents · Next section
4. Case A: the on-chain reference changes
At a later accepted block B120, the same contract and token ID still identify H, but the metadata reference is now U2. The supplied model permits that update. Retrieving U2 produces document M2, which refers to F2.
What remains the same? The identified network, contract, token ID and supplied holder relationship. What changes? The reference returned at the later state and the content reached through it.
The record of what U1 produced at T1 remains a historical observation. It does not become false merely because the current reference is different. Equally, the B100 observation does not establish that the current token reference still identifies M1.
What about permission? L1 was stipulated to cover H’s classroom display of F1. Nothing in this variation extends it to F2. The correct conclusion is that permission for F2 has not been supplied. It would be a mistake to copy the old permission conclusion onto a new file just because the token number is unchanged.
This case shows why reports need both a state reference and a content version. Token identity can remain stable while a related reference changes. Whether a real implementation permits such a change is an implementation question, not something to assume for every NFT.
Back to contents · Next section
5. Case B: the reference stays, but the returned bytes change
Return to the baseline. In this independent case, the chain still returns U1. At T1, U1 produced M1. At T2, the same ordinary web reference produces a different document, M2. The supplied evidence confirms that the retrieved bytes differ.
The token reference has not changed in this case. The external response has. A report that checks only whether the tokenURI string stayed the same would miss the difference.
The accurate statement records both retrievals: same reference, different response versions at different times. It should not say that the token itself necessarily changed, or that the old document never existed. Those claims go beyond the supplied observations.
This variation also prevents a common shortcut: treating a familiar URL as a content commitment. A location reference tells the reader where a request was directed. Whether its response is fixed requires additional evidence about how that resource is identified and maintained.
If permission depends on an identified version of F1, the reviewer must preserve that binding. A new metadata response does not silently expand the permission to whatever image is now displayed. Conversely, a changed response does not by itself settle whether an earlier permission remains effective. That is outside this toy’s supplied change rules.
Back to contents · Next section
6. Case C: the image cannot be retrieved
Return to the baseline again. The chain observation still identifies N/42 and H. U1 still returns M1, including the image reference. At a later attempt, the observer cannot retrieve F1 through the tested route.
Several statements remain supported: the identified token record was observed, the metadata document was retrieved, and the image reference was present. The later image retrieval failed. These facts should appear separately in the report.
The failed attempt does not establish that every copy of F1 has vanished. It describes the tested route and time. An unavailable server, a temporary network problem or another cause might explain the observation, but the exercise does not identify which cause occurred.
It also does not establish that the chain record was destroyed, or that L1 was cancelled. Availability and permission are separate dimensions. In this case we simply cannot complete the proposed viewing task through the observed retrieval path.
A useful next evidence request concerns the content and the retrieval arrangement: which retained copy, which verified version, and which service evidence can support access? Repeating the owner lookup would not repair the missing image, because that lookup answers a different question.
No real hosting action is required here. The lesson is to diagnose the missing evidence layer accurately before deciding what further investigation would help.
Back to contents · Next section
7. Case D: content verification succeeds, but authority is unknown
In this independent variation, the image is retrieved through a content-addressed representation, and correct verification establishes that the returned content matches the specified reference. The relevant encoding and verification procedure are supplied as correct assumptions.
However, the packet no longer supplies evidence that the person making the permission claim is authorised to do so. A website says “all uses allowed,” but its authority and applicability to this image are unknown.
The successful content check remains valuable: it links the retrieved representation to the identified reference under the assumed verification rules. It does not fill the missing authority field in the permission record.
A technically accurate copy can be accompanied by an unverified claim about who may use it. Likewise, two websites can serve matching content while making different statements about permission. Matching bytes alone does not decide which statement has authority.
For this exercise, mark the content-integrity connection as supported and the permission claim as unresolved. Do not downgrade the verified content match merely because another question is open, and do not upgrade the permission claim merely because the content match succeeded.
This is a useful general habit: a check should change the conclusion it actually tests. It should not spread confidence automatically to every label displayed nearby.
Back to contents · Next section
8. Cases E and F: a broader claim and a later holder
Case E returns to the full baseline, including the stipulated authority of L1. A display page adds the sentence “The holder may use this image commercially.” No additional programme permission is supplied.
Under the invented evidence rules, the packet supports H’s classroom display. It does not support the broader commercial-use statement. The page’s assertion is evidence that someone made that assertion, not evidence of an additional valid grant. We are comparing the supplied documents, not issuing a legal judgment about a real dispute.
Case F also starts from the baseline. A later accepted state identifies J in the token’s owner field after a supplied valid token transfer. The content remains F1. No rule says that H’s programme permission automatically passes to J, and no new permission for J is supplied.
The chain-record conclusion changes: J is now the supplied recorded holder. The content conclusion does not change. The permission conclusion for J remains unestablished because the necessary rule or grant is missing.
This does not prove that J could never obtain permission. It identifies what the packet currently fails to establish. It also does not determine whether H retains any permission after the transfer, because the fictional programme has not supplied that termination rule either.
The right answer to a missing rule is an unresolved field, not a rule invented from the direction of the token transfer.
Back to contents · Next section
9. Write a version-specific evidence report
A useful report can be short without flattening the layers. Begin with the exact record context: network, contract, token ID and state. Then record the metadata reference and the version actually retrieved, including retrieval time and source.
Next identify the media representation that was obtained and what verification, if any, was performed. Separate successful integrity verification from an assumption about who created the work. Add the observed availability scope: one successful retrieval now does not describe every future time.
Finally state the permission evidence. Identify the purported granting party, the covered content, recipient or eligibility condition, permitted use, applicable version and any unresolved authority or applicability questions. In our toy these are supplied programme facts; in a real matter their legal effect would need separate assessment.
For the baseline, the report can say: “C/N/42 at B100 identifies H. At T1, U1 produced M1 and its referenced F1 was retrieved. The supplied programme record L1 permits H’s classroom display of F1. No commercial-use grant, future-hosting commitment or successor-holder permission rule is supplied.”
That statement is more useful than a badge saying “verified NFT.” It tells the reader what was checked and what remains open. It also makes updates easier: a changed pointer, failed retrieval or new permission document affects a named field rather than forcing an all-or-nothing verdict.
Back to contents · Next section
10. Keep the jurisdiction boundary visible
The distinction between a token record and rights in associated content has also been discussed in public policy research. The USPTO and U.S. Copyright Office joint report, published on 12 March 2024, discusses confusion over NFT-related intellectual-property rights in its U.S. legal context.
That report is background, not a statement of mainland Chinese law or a determination of the fictional programme’s legal effect. This lesson’s answers follow the explicitly supplied permission cards, not an assumed universal licensing rule.
For an actual use of content, a technical record alone is insufficient to settle the permission question. The relevant agreement, granting authority, content identity, intended use and applicable rules matter. If those are disputed, the appropriate conclusion in a technical evidence worksheet is to identify the dispute and the missing evidence rather than pretend the chain has resolved it.
This boundary does not reduce the usefulness of the technical record. It preserves its proper role as one part of a larger evidence chain.
Back to contents · Next section
11. Exercises with answers
Exercise 1: Same token, different reference
In Case A, does an unchanged token ID establish that H’s existing permission covers F2?
Answer: No. L1 covers the supplied F1 classroom use. A different file requires evidence that the permission applies to it. The unchanged token identity does not supply that connection.
Exercise 2: Same reference, different response
In Case B, which observation changed: the on-chain reference or the retrieved metadata bytes?
Answer: The retrieved metadata bytes changed. The reference remained U1. Reports should preserve both versions and retrieval times rather than treat the unchanged reference as proof of unchanged content.
Exercise 3: Missing image
In Case C, can the observer conclude that the token was destroyed and all image copies disappeared?
Answer: Neither conclusion follows. The token observation remains supplied; the failure concerns the tested image retrieval route and time. Global disappearance is not established.
Exercise 4: Matching content
In Case D, content verification succeeds. Does that validate the website’s unrestricted-use claim?
Answer: No. The content match is supported, but the claimant’s authority and applicable permission are missing. Keep those conclusions separate.
Exercise 5: New holder
In Case F, what additional evidence is needed before attributing H’s stated permission to J?
Answer: A supplied applicable rule or grant establishing J’s permission. The token’s recorded transfer alone does not answer that question in this model. H’s continuing permission is also unresolved without a termination rule.
Back to contents · Next section
12. Frequently asked questions
Can two tokens refer to the same image?
A unique token identifier does not itself prohibit another record from referencing the same content. Any uniqueness claim about the content or associated entitlement requires additional evidence beyond the identifier’s local uniqueness.
Does a content identifier guarantee future access?
It helps identify a representation for verification. Continued retrieval also depends on retained data and an available retrieval path. Do not treat the identifier as a perpetual hosting promise.
Is every NFT’s metadata changeable?
No such generalisation is supplied here. Case A explicitly gives a model that permits a reference update. A real implementation must be assessed on its own rules and configuration.
Does “unresolved permission” mean the use is definitely forbidden?
It means the packet does not establish the permission being claimed. This exercise does not convert missing evidence into a universal legal conclusion.
Back to contents · Next section
13. Sources and further reading
Sources checked on 12 October 2026. All token records, files, permission cards and cases in the workshop are fictional.
- ERC-721: Final; created 24 January 2018; optional metadata interface and unique identifiers.
- IPFS content identifiers: representation-aware content identification and verification.
- IPFS pinning: retention mechanisms and local/remote scope.
- USPTO–USCO joint NFT report: 12 March 2024; explicitly U.S.-scoped background.
- How Blockchain Works: broader introductory context.
The record, the referenced bytes, their availability and permission to use them are connected questions. A reliable explanation makes every connection visible and leaves missing connections honestly unresolved.