In January 2020, OpenSea published an example of a CryptoKitty named Duke Khanplum. Its ownership could be verified through an Ethereum smart contract, but the image representing the cat lived somewhere else: a Google Cloud Storage URL.
The distinction was easy to overlook. Anyone viewing the NFT through a marketplace would see the artwork and ownership information together, as though both belonged to the same permanent record.
They did not.
Ethereum recorded the token’s ownership and supported the rules governing its transfer. The image depended on an external storage service continuing to make the file available.
If that image became inaccessible, the blockchain would not automatically lose track of the token. Its owner could still hold the NFT, even if a wallet or marketplace could no longer display the artwork.
That separation is not unique to early NFT collections. It remains a defining feature of many digital collectibles, including projects that use decentralized file storage rather than ordinary web servers.
The technical distinction matters because an NFT can be permanent in one sense and fragile in another.
A smart contract may continue recognizing its owner. The metadata describing the NFT may remain intact, change, or become unavailable. The image itself may depend on a separate storage network, software library, or rendering service.
These are different components, each with different failure conditions.
Ravel examined the documented storage architecture and source code associated with four NFT examples: CryptoKitties, Bored Ape Yacht Club, Nouns, and Chromie Squiggle.
The comparison reveals why the blockchain holding an NFT is not always the system responsible for preserving what its owner sees.
What Ethereum Actually Stores When Someone Buys an NFT
ERC-721 provides the foundation for many Ethereum NFTs.
The standard defines how unique tokens are identified, how ownership can be checked, and how authorized transfers occur.
A contract implementing ERC-721 can maintain a record showing that a particular Ethereum address owns a particular token ID. That record exists independently of whether a marketplace can display the artwork associated with the token.
The official ERC-721 specification also defines an optional metadata extension.
Its tokenURI function allows applications to locate descriptive information about a particular NFT. The function may return a URI pointing to JSON metadata, including fields such as the asset’s name, description, and image.
Importantly, the standard does not require the underlying image to be embedded in the blockchain.
Consider a hypothetical NFT identified by token ID 42.
An application could query the contract to determine which wallet owns token 42. It might then request the token’s metadata URI.
The metadata could point to a JSON document containing a link to an image file.
The complete process therefore involves several distinct operations.
First, Ethereum identifies the owner. Next, the application retrieves the metadata. Finally, it locates and displays the image referenced by that metadata.
Successful completion of the first operation does not guarantee successful completion of the others.
An NFT owner can retain control of the token while the metadata server stops responding.
A metadata document can remain available while the image it references disappears.
And a marketplace can fail to display artwork even when both the metadata and image remain retrievable elsewhere.
These situations should not be confused.
A broken marketplace thumbnail is not automatically evidence that the underlying NFT media has been lost. The application might have a caching problem, an unsupported file format, or a malfunctioning gateway.
Equally, seeing an image on a marketplace does not establish that the original artwork is safely preserved.
The marketplace may be displaying a cached copy rather than retrieving the original file.
This separation is why the word ‘on-chain’ requires some precision.
The NFT ownership record may be on-chain. Its metadata may be off-chain. Its artwork may live somewhere else again.
Without examining those layers separately, it is difficult to assess what will survive if the original project disappears.
Four NFTs Reveal Four Different Dependencies
Ravel compared four documented NFT implementations to identify where their artwork comes from and which external components are involved.
The examples cover three broader storage approaches: conventional hosting, content-addressed storage, and on-chain reconstruction.
Within on-chain reconstruction, Nouns and Art Blocks offer two substantially different implementations.
CryptoKitties: an on-chain collectible with externally hosted imagery
CryptoKitties provides an early example of separating a token’s blockchain-based attributes from its visual representation.
In its 2020 NFT technical overview, OpenSea documented CryptoKitty #1500718, Duke Khanplum.
The example metadata referenced a PNG file hosted on Google Cloud Storage.
That URL was an address for retrieving the artwork, not a record of the image’s binary contents stored inside Ethereum.
The distinction is particularly interesting because CryptoKitties also maintains important information about the digital cats within its blockchain contracts, including genetic attributes used by its breeding system.
Those on-chain characteristics are not equivalent to storing the complete rendered image on Ethereum.
A program can preserve the information needed to describe a character while still relying on separate software or infrastructure to display that character.
The 2020 example establishes the architecture used in the documented case. It is not proof that the same image endpoint is available or unavailable in October 2026. Ravel has not established its current uptime through a successful direct retrieval.
That distinction matters because the purpose of the comparison is to identify storage dependencies, not to declare that a particular NFT has disappeared.
Bored Ape Yacht Club: decentralized storage with external availability requirements
Bored Ape Yacht Club uses a different approach.
Its metadata and images have been distributed through IPFS, the InterPlanetary File System.
Rather than identifying content solely by a conventional server location, IPFS uses content identifiers derived from the data.
This allows someone possessing the correct content identifier to retrieve and verify the corresponding file from any available provider that hosts it.
The BAYC contract’s verified source code includes a base URI mechanism used to construct metadata locations.
A token’s metadata URI can refer to a file within an IPFS directory. That JSON document then references the artwork through another IPFS content identifier.
The ENS avatar specification provides a concrete example using BAYC token #0 and its IPFS-hosted image.
This architecture creates two off-chain content resources for a typical NFT display: the metadata document and the image file.
The use of IPFS gives those resources content-addressed identities. It makes unintended file modification detectable because changing the content produces a different identifier.
But identifying a file and keeping a copy of it available are different problems.
The content identifier can remain perfectly valid even when the network has no reachable provider holding the corresponding data.
There is another detail in BAYC’s implementation worth noting.
The verified contract source includes an owner-restricted setBaseURI function, demonstrating that the original design incorporated administrative authority over the metadata base URI.
Whether that authority is currently exercisable requires examining the present on-chain owner and contract state. The existence of the function in the source code does not establish that the collection’s metadata can still be changed today.
Nevertheless, the architectural distinction is important.
Content-addressing can protect a particular file against undetected changes. It does not automatically prevent a separate, authorized change to the pointer telling applications which file to retrieve.
Nouns: artwork generated from Ethereum data
Nouns takes a more direct approach to preserving artwork.
Rather than depending on an externally hosted image file for each token, the project stores compressed image components on Ethereum.
Those components are converted into an SVG image using smart-contract logic.
The Nouns project’s technical explanation describes how its image parts use run-length encoding to reduce storage requirements.
The data can then be decoded and assembled into an image.
The official NounsToken source code shows how its tokenURI and dataURI functions rely on a descriptor contract and the token’s stored seed.
A supporting SVG renderer constructs the visual output from the stored components.
That means the token’s artwork can be reconstructed from blockchain data without requiring an external PNG or JPEG file to remain hosted by the original project.
There is a subtle qualification, however.
Nouns’ source code also contains mechanisms for changing the descriptor or seeder while the corresponding configuration has not been locked.
These functions demonstrate that storing artwork components on-chain and making the rendering configuration permanently immutable are distinct design choices.
Their current lock status must be checked on-chain before concluding that a specific component can still be replaced.
Another detail reinforces the importance of examining metadata separately: Nouns’ contract-level contractURI points to IPFS even though the token-specific artwork is generated on-chain.
Thus, the storage classification can depend on which information is being evaluated: an individual token’s artwork or supplementary collection metadata.
Chromie Squiggle: an algorithm rather than a stored picture
Art Blocks introduces another variation.
For generative projects such as Chromie Squiggle, code produces the artwork.
The essential creative object is not necessarily a pre-rendered image file. It is an algorithm that uses an on-chain token hash to generate a visual result.
In its on-chain storage documentation, Art Blocks explains how to retrieve Chromie Squiggle’s project script and token-specific hash from Ethereum.
Its Dependency Registry also stores the p5.js v1.0.0 software library used by this early project.
Art Blocks has developed an on-chain generator that can assemble browser-viewable HTML from the relevant blockchain records.
For Chromie Squiggle token #0, the documented procedure uses the original Art Blocks core contract and the token ID to reconstruct the work.
That design addresses a problem faced by externally hosted artwork: the source material needed to recreate the piece does not have to disappear when a particular website shuts down.
But there is still a distinction between preserving the algorithm and displaying the result.
The browser must execute the program. The software environment must support the required rendering operations.
Art Blocks also maintains APIs that serve ready-made images and live previews to websites and marketplaces.
If those APIs become unavailable, users may temporarily lose convenient access to the artwork’s display even though the underlying program remains reconstructible from Ethereum.
The preservation of the artwork’s source is stronger than the availability of any one website showing it.
Those are not identical guarantees.
Ravel’s NFT Storage Reality Check
We can compare the four cases by identifying the resources essential for reconstructing their documented visual output.
| NFT example | Artwork mechanism | Off-chain dependency |
|---|---|---|
| CryptoKitties #1500718 | Externally hosted rendered PNG in the documented historical example | Image-hosting endpoint |
| BAYC #0 | IPFS-hosted metadata and image | Availability of metadata and image files |
| Nouns #316 | On-chain image components and SVG renderer | No external image file is required for reconstruction |
| Chromie Squiggle #0 | On-chain generative script, token hash and dependencies | No external artwork-hosting service required for documented reconstruction |
Methodology: This comparison is based on official technical documentation, published examples, and contract-source architecture. It is not an independent live-availability audit of all four assets or their current hosting providers.
The table exposes a useful difference.
In the CryptoKitties example, the documented display path requires at least one external image resource.
For the illustrated BAYC path, an application normally retrieves an external metadata document and then the external artwork referenced by that document.
In the Nouns and Chromie Squiggle examples, the relevant artwork can instead be constructed using blockchain-stored information.
That does not make the latter two immune to every possible form of loss or display failure. It means they remove a particular dependency: the continued hosting of an independent artwork file.
IPFS Preserves a File’s Identity, Not Its Availability
BAYC’s architecture highlights one of the most misunderstood properties of decentralized storage.
IPFS uses content addressing.
A file is identified by a content identifier, or CID, derived from its contents rather than the name of a server storing it.
If someone changes the original file, the modified data produces a different content identifier.
This provides an integrity guarantee: the CID helps establish whether retrieved data matches the content originally identified.
It does not provide an unconditional availability guarantee.
The official IPFS persistence documentation distinguishes persistence from permanence and explains why pinning is needed to prevent locally stored content from being removed during garbage collection.
A node participating in IPFS may download and cache a file. But that node does not necessarily promise to keep the file indefinitely.
When storage resources are needed elsewhere, unpinned content can be removed.
Pinning allows a node or storage service to retain a particular CID and continue making its data available.
Multiple independent providers can improve resilience because the loss of one provider does not necessarily make the content inaccessible.
Still, maintaining those copies requires infrastructure and ongoing participation.
Consider a hypothetical NFT image stored on IPFS.
Its content identifier exists in the token’s metadata.
Initially, three independent nodes hold copies of the image.
If one stops serving it, the other two may continue responding.
If the second disappears, the final node can still provide the file.
But if no reachable node retains the data, the CID by itself cannot reconstruct the original image.
The NFT may continue pointing to the same identifier. The cryptographic reference has not changed.
What has changed is the availability of the data behind it.
This is the crucial difference between knowing exactly which file should exist and actually possessing that file.
It also explains why a failed IPFS gateway request should be interpreted carefully.
A gateway is one route for retrieving IPFS content through an ordinary web browser.
A gateway outage does not necessarily mean the content is unavailable across the network.
Another gateway or IPFS node may be able to retrieve it successfully.
Conversely, the fact that one gateway still serves a file does not prove the file is stored redundantly by numerous independent providers.
One available copy may be enough for retrieval at that moment, but it provides a different level of resilience from several independently maintained copies.
For an NFT collector, the relevant question is therefore not simply whether the metadata contains an ipfs:// address.
It is whether the content is still available, who maintains copies, and what arrangements exist to preserve it over time.
Content integrity and content persistence must be evaluated separately.
Fully On-Chain Art Solves One Risk but Not Every Risk
A fully on-chain NFT changes the preservation problem.
When the data or program required to recreate an artwork is stored on Ethereum, it no longer depends on an external storage provider retaining a separate image file.
Nouns demonstrates this through compressed image components and SVG rendering.
Chromie Squiggle demonstrates it through generative code and token-specific inputs.
The two designs are different, but they share an important advantage: the primary creative information can be recovered from the blockchain, assuming the chain and its historical state remain accessible.
This reduces exposure to abandoned web servers and lost off-chain artwork files.
Yet on-chain storage and immutable presentation are not automatically the same thing.
A smart contract may contain permissions allowing an authorized party to change a renderer, descriptor, or other component that determines what users see.
Whether the artwork can change depends on the contract’s actual restrictions and current configuration.
The Nouns descriptor mechanism illustrates this point particularly well.
Even when the raw artwork components remain on Ethereum, the contract’s design determines which renderer or descriptor a token uses.
If a changeable component affects the generated result, a token’s appearance may depend on more than the original storage of its pixels or shapes.
The distinction resembles an application storing an image-generation recipe rather than a finished image.
Preserving the ingredients does not alone establish that the recipe can never be changed.
For algorithmic artwork, another consideration is the ability to reproduce the output.
A preserved generative script is valuable only when its required dependencies and execution environment can be reconstructed.
Art Blocks’ effort to put software libraries into its Dependency Registry addresses precisely this problem.
The Art Blocks on-chain generator documentation describes how project scripts, token hashes, and registered software dependencies can be assembled into output viewable in a browser.
The system is designed to reduce reliance on the platform’s own hosting infrastructure.
However, not every Art Blocks project has the same dependency architecture.
Some Engine Flex implementations can use assets on IPFS or Arweave, and other projects may rely on libraries that have not been fully embedded on-chain.
It would therefore be inaccurate to describe all generative NFTs as completely self-contained simply because their core creative scripts are recorded on Ethereum.
There is also a difference between a permanent source and a permanent user experience.
An ordinary collector may depend on a marketplace to show a thumbnail, play an animation, or display a rendered preview.
Those conveniences can disappear when a website or API stops operating.
A technically sophisticated user may still be able to reconstruct the work independently.
The difference reflects the resilience of the underlying content rather than the uninterrupted operation of every interface built around it.
OpenSea now makes some of these distinctions more visible.
In February 2026, the marketplace introduced metadata storage labels on NFT pages, including ‘Fully on-chain’, ‘On-chain metadata’, ‘Decentralised’, ‘Centralised’, and ‘Unknown.’
The categories recognize that blockchain ownership, on-chain metadata, and externally stored media do not always belong in the same classification.
OpenSea also cautions that its classifications are generated programmatically and may not be accurate for every project.
That qualification is important.
A label can help users identify where to investigate. It cannot replace an examination of the relevant smart contracts, metadata, and content dependencies.
What an NFT Owner Should Verify Before Trusting Its Permanence
The most useful way to evaluate an NFT’s durability is to trace how its artwork is obtained.
For a conventional ERC-721 collectible, the investigation begins with the token contract.
The first question is whether the token’s metadata comes directly from contract execution or from a URI pointing elsewhere.
If the contract returns an HTTPS address, the collector should identify the operator responsible for that endpoint.
If it returns an IPFS address, the collector should examine whether the referenced data is available and how its persistence is maintained.
If it returns on-chain encoded metadata, the next step is to establish whether the underlying media is also embedded or generated on-chain.
The image field deserves particular attention.
An NFT may have metadata stored permanently in one location while its image references an external resource with weaker availability guarantees.
Examining only the metadata URI can therefore overlook the actual dependency that holds the artwork.
The permission structure matters as well.
A contract can include administrative functions that change metadata locations or rendering components. Understanding whether those functions remain usable requires checking the contract’s current ownership, roles, and locking mechanisms.
For generative art, the investigation extends to software dependencies.
The collector needs to know whether the project’s code, token-specific inputs, required libraries, and external assets can be recovered without relying on the original project’s website.
Finally, the collector should distinguish a display failure from a preservation failure.
A blank image in one wallet may be a local application problem.
An unavailable gateway may be a temporary access problem.
The loss of the last available copy of an externally stored artwork is a much more serious problem because the reference alone cannot recreate the missing data.
Independent backups and redundant storage can reduce that risk.
But preserving a private copy also requires care. A file copied from an unknown source is not automatically authentic merely because it resembles the NFT’s image.
A content identifier or another verifiable commitment can help establish whether the copied data matches the intended original.
This is where blockchain technology and decentralized storage can complement one another.
The blockchain can establish token ownership and store or commit to information about an asset.
Content-addressed storage can help preserve the identity of the referenced data.
Persistent hosting arrangements keep that data retrievable.
When the complete artwork is stored or reconstructible on-chain, one of those external dependencies can be reduced substantially.
None of these properties should be mistaken for a universal guarantee that every interface will display the asset forever.
The four NFT examples illustrate different ways of distributing responsibility between smart contracts, files, storage providers, and rendering systems.
CryptoKitties shows how an early NFT could retain blockchain-based identity while displaying artwork from an external server.
BAYC demonstrates how IPFS can make externally stored content independently identifiable without guaranteeing indefinite availability.
Nouns shows how compressed artwork data can live on Ethereum, while contract configuration remains a separate matter to inspect.
Chromie Squiggle shows how an artwork can be preserved as reproducible code rather than as a fixed hosted image.
They share one underlying principle.
Ownership records and the visual objects associated with them are not necessarily preserved through the same mechanism.
The fact that an NFT remains in a wallet establishes something important about the token.
It does not, by itself, establish that the file, software, or infrastructure required to display its artwork will remain available.
Owning an NFT on Ethereum can preserve the ownership record. Preserving the artwork requires understanding what the token actually points to, and who, or what, keeps that content alive.
