How Blockchain Works | NFTs, Metadata and Linked Files

A fictional library club creates digital badges for a reading exhibition. A screen shows a badge number, a name and a picture of an invented owl.

It looks like one object. Underneath, several objects may be involved: a token record, descriptive metadata, an image file and a website that displays them together.

An NFT, or non-fungible token, is not automatically the entire picture-and-description package stored in one place.

Our club badge has no price and is not a product recommendation. It is a paper model for understanding the technical relationships.

Start by drawing separate boxes for the token, metadata and image. Put the display in a fourth box. We will ask which connection each box needs and what remains if one part changes or stops being available.

Contents · Next chapter

The fictional badge has token number 17. Another club can also use number 17. The number alone does not identify the same token everywhere.

For an ERC-721-style record, the contract address and token identifier are important parts of the context, along with the network.

A familiar collection name or picture is not a substitute for those identifiers. Different contracts can use similar descriptions.

This is the same lesson encountered in block explorers: context determines what a label refers to.

Our evidence note says Practice Network, Badge Contract C, Token 17. These are clearly invented labels, not live addresses.

The note identifies the ledger object before making claims about its contents or associations. That is a more reliable starting point than assuming that a matching image proves two displays concern the same token.

Contents · Previous chapter · Next chapter

The fictional club tracks badge 17 separately from badge 18. The program can refer to each token’s identity instead of treating every unit as interchangeable for its intended purpose.

This is the basic contrast with a fungible counter model, where equal units can serve the same accounting role.

Non-fungible does not mean the associated picture cannot be copied. Nor does it mean no other token can refer to a similar image.

The distinguishable ledger identifier and the uniqueness of an outside file are different questions.

Our club might deliberately issue several distinct exhibition badges using the same owl illustration. The token records would still be separate in the defined contract.

The beginner lesson is to ask what is unique: the token identifier in context, the file bytes, a particular permission or an outside object. The adjective unique cannot safely answer all of these questions at once.

Contents · Previous chapter · Next chapter

The fictional contract records a holder for badge 17 under its rules. An accepted transfer can change that recorded holder.

That is a statement about the token’s ledger state. It does not automatically describe where the image file is stored or who may edit the exhibition website.

The word ownership can hide several meanings, so this guide keeps the ledger relationship separate from file access and rights.

A reader should be able to say, “This contract reports this holder for this token at this reference point,” without adding unsupported conclusions.

An address still needs careful interpretation. It is not automatically a named person, as the identity guide explains.

Once the token record is identified, we can follow its descriptive connections. The next question is not who drew the owl, but how the display obtains the information it shows beside the token.

Contents · Previous chapter · Next chapter

Metadata is descriptive information associated with an object. For the fictional badge, it might contain a name, a description and a reference to an image.

ERC-721’s optional metadata extension defines a way to obtain a token URI. That URI may lead to a description following the relevant format.

Optional matters. Do not assume every token or implementation supplies the same fields or uses the same storage arrangement.

Our paper metadata card says Name: Library Owl Badge; Description: Fictional exhibition example; Image reference: Owl File A.

The card is not the token itself. It describes or points to associated material.

Separating these objects makes the display easier to understand. A website can combine a ledger record with external descriptive data, but the final visual package does not prove that every part was stored on the chain.

Contents · Previous chapter · Next chapter

A uniform resource identifier, or URI, provides a defined reference to a resource. Its scheme and use determine how an application interprets it.

In our fictional badge, the token’s URI points to the metadata card. The card then points to the image.

This can create a chain of references rather than a single direct link from token to picture.

A reference does not automatically guarantee that a service will keep returning the resource forever. The relevant storage and access arrangements need their own explanation.

Draw the arrows as well as the boxes. Which component supplies the first reference? Which retrieves the metadata? Which then retrieves the file?

The exercise helps clarify a common sentence: “The picture is on blockchain.” That sentence may mean the file itself is stored through the chain, or it may mean only that a token points toward information located elsewhere.

Contents · Previous chapter · Next chapter

The fictional metadata card points to an image stored by the exhibition’s file service. The ledger holds the token relationship, while another component serves the owl picture.

This is a possible design, not a claim about every NFT. Some designs place more content on-chain; others use external storage or combinations.

The important question is where the actual bytes needed to render the image come from.

A successful token query does not automatically establish successful image retrieval. The two paths can fail independently.

Our club’s screen may show the correct token holder while displaying a broken-image symbol. That does not by itself mean the token vanished.

This distinction connects the NFT guide to data availability. A durable reference and a retrievable file are separate responsibilities. The architecture should name who preserves the file and how readers can obtain it.

Contents · Previous chapter · Next chapter

Some storage systems identify content through a relationship to its bytes. If the file changes, the corresponding content identifier changes according to that system’s rules.

This can help distinguish a particular version from another. It is different from asking a server for whatever file currently sits at a location.

The file still has to be supplied. An identifier is not a reversible compressed copy from which an absent image can be reconstructed.

Our fictional exercise labels Owl File A and Owl File B as different byte versions. We do not calculate real identifiers.

The useful contrast is between identifying the expected content and keeping it available. A system can perform the first job well while needing ongoing providers for the second. Both jobs matter if a future reader is expected to see the same associated image.

Contents · Previous chapter · Next chapter

IPFS documentation distinguishes content addressing from persistence. Data remains obtainable only when suitable nodes retain and serve the necessary content.

Pinning is one mechanism for retaining data on nodes rather than allowing ordinary garbage collection to remove it. It is not a promise that every unrelated participant stores the file indefinitely.

Our fictional club assigns a file-retention responsibility instead of assuming the network remembers everything without cost or maintenance.

The lesson is conceptual, not a recommendation for a storage provider. Real arrangements differ in operation and guarantees.

Ask who retains the file, how service continuity is supported and what happens if a provider stops. The existence of a content reference does not answer those operational questions.

A truthful explanation separates a stable identifier from a durable preservation plan. They can complement each other, but neither should be mistaken for the other.

Contents · Previous chapter · Next chapter

The fictional badge’s description changes from Exhibition Preview to Exhibition Open. Whether and how that change is possible depends on the contract and metadata design.

A token’s associated description is not universally frozen merely because the token has a blockchain record.

Some references can change through authorised operations. Some locations can serve changed content. Other designs bind particular bytes more tightly.

ERC-4906 provides a metadata-update event extension for certain ERC-721 applications. Its existence illustrates that updates are an explicit concern in the ecosystem, not proof that every collection behaves the same way.

For a beginner, ask which component can change and who has authority to change it. A statement such as immutable should identify whether it concerns the token rules, a URI, metadata bytes, an image or some combination of them.

Contents · Previous chapter · Next chapter

The fictional exhibition website caches the preview image. The metadata source now points to the open-exhibition image, but the website has not refreshed its stored copy.

Two displays can therefore show different pictures while referring to the same token context.

The difference may concern caching or indexing rather than a disagreement about the token’s current holder.

Do not infer the cause from the picture alone. Compare the token context, returned reference, retrieved content and observation time.

Our paper model keeps a copy of the old display beside the new metadata card. The mismatch is easy to see once the objects are separate.

This is the same systems habit used throughout the series: identify which layer supplied the claim. A website’s visible rendering is evidence about that rendering, not automatically a complete statement about every underlying component.

Contents · Previous chapter · Next chapter

The fictional badge records a holder and refers to the owl drawing. Those technical facts do not, by themselves, specify every right to reproduce or commercialise the drawing.

IPOS explains that NFT ownership should not be assumed to equal ownership of the intellectual-property rights in the underlying asset. The applicable rights depend on what has actually been granted.

This guide gives a general distinction, not legal advice about a particular token or artwork.

For our paper badge, use an invented drawing and a clearly stated fictional permission note. Keep that note separate from the token-transfer record.

The beginner question is simple: which evidence supports the claimed permission? A holder query answers a ledger question. A licence or other relevant rights arrangement answers a different question. The fact that an interface puts both ideas beside one image does not make them the same thing.

Contents · Previous chapter · Next chapter

The fictional club creates a badge referring to a physical display board. Recording the reference does not make the contract a camera that watches the board.

If someone removes or replaces the physical object, the digital reference may remain unchanged unless the system receives and processes relevant information.

This is the oracle and supply-chain boundary again. A digital record can support a defined association, while the outside facts require additional evidence.

Avoid describing every NFT as automatic proof that a physical item exists, is authentic or is currently held by a named person.

Our club’s paper note distinguishes the token identifier from the evidence about the board. That separation makes the checking task clearer.

The general lesson extends beyond art: a label for an outside thing is not the same as continuous observation of that thing.

Contents · Previous chapter · Next chapter

Badge 17 and badge 18 both point to Owl File A. Another fictional contract uses the same image too.

The image can be identical while the tokens remain different ledger objects.

This demonstrates why a picture is a poor standalone identifier for a token. It also demonstrates why the word unique needs a precise object.

The token identifier, file bytes and authority claims can vary independently.

For our classroom exercise, draw three token cards with different contract-and-number contexts and connect them to one file card. Then ask what each query could establish.

The drawing does not require minting anything. It simply shows a many-to-one reference relationship.

A reader who understands that relationship is less likely to infer exclusive rights, a single issuer or a single token merely from seeing the same thumbnail on several pages.

Contents · Previous chapter · Next chapter

The fictional image service becomes unavailable. The token record and its reference still exist, but the exhibition screen cannot retrieve the picture through that route.

A careful report says which retrieval failed, from which source and at what time. It does not immediately claim that every copy has been destroyed.

Someone may retain another copy. The expected reference can help assess whether a retrieved copy is the intended version, depending on the scheme.

This is why the preservation plan matters before the failure.

Our exercise leaves the file card on the table but removes its connection to the current display. The file may exist while this reader cannot reach it.

Existence, integrity, retrievability and convenient rendering are separate properties. A single broken thumbnail cannot answer all four questions, and a single working thumbnail cannot guarantee them indefinitely.

Contents · Previous chapter · Next chapter

Describe the fictional badge with four lines: token context, metadata source, file reference and relevant permission statement.

Add the observation time and the status of each retrieval. If a component was not checked, say so.

For example, the note can establish that Badge Contract C reports token 17, its current metadata card refers to Owl File A and the display retrieved that file during the exercise.

It should not add claims about creator identity or rights without their own evidence.

This is an explanation method, not a checklist for buying NFTs. No purchase is needed to understand the architecture.

The four-part note is useful because it prevents the finished image on a screen from hiding its dependencies. A reader can see exactly which objects were examined and which conclusions belong to each object.

Contents · Previous chapter · Next chapter

Draw Token 17, Metadata M, Owl File A and Display D. Connect the token to M, M to A and D to the sources it uses.

First change only the display’s cached picture. Ask which underlying objects changed.

Next make M point to Owl File B through an authorised fictional mechanism. Ask why the token number can remain the same while the visible image changes.

Then remove the file provider and discuss what the surviving references establish.

Finally add a separate permission note and explain why it cannot be inferred from the holder field alone.

Every label is fictional and no real token is created.

The exercise is complete when a reader can describe token identity, descriptive references, data service and permission evidence without using one word such as ownership or permanence to cover the entire route.

Contents · Previous chapter · Next chapter

An NFT display can bring together several distinct systems: a ledger record, metadata, file storage and an application interface.

Understanding that arrangement is more useful than assuming the picture itself must be wholly on-chain or permanently available.

Carry four questions into the technical companion. Which token is meant? Where do its description and file come from? What can change? Which separate evidence supports any rights or outside-object claim?

Our fictional badge shows why the answers can differ. A token can remain while a file route fails. A display can lag behind its source. Several tokens can point to the same image.

The goal is a clear account of the connection, not a verdict on every use of NFTs. Precise references and scoped claims let a beginner understand what the record actually does.

Contents · Previous chapter · Worked situations