Skip to content
HAZELSBlog
Enter Studio

What "immutable" actually guarantees

The word does a great deal of work in NFT marketing and almost none of it survives contact with how metadata is really stored. What the chain fixes in place, and what stays editable.

4 min readupdated 5 September 2026

A solid ivory block secured to a black base connects by a red cord to a floating translucent document.
A solid ivory block secured to a black base connects by a red cord to a floating translucent document.

"It's on the blockchain, so it can't be changed" is true about a very specific thing and false about most of what people assume it covers.

What is genuinely fixed is the record of transactions: that this address minted this token id at this block, and that ownership moved in this sequence. That history is what the chain is for, and it is as durable as the network.

Everything else — the name, the picture, the traits, the description — depends entirely on how the collection was built. In most collections, all of it is editable, and in many the ability to edit it belongs to one address.

The chain of custody for a picture

Follow what actually happens when a marketplace shows you an NFT.

  1. It asks the contract for the token's tokenURI.
  2. The contract returns a string. Usually a URL.
  3. The marketplace fetches that URL and gets a JSON document with the name, description, traits and an image field.
  4. It fetches the image from wherever that field points.

Three of those four steps happen off-chain. Each one is a place where the answer can be different tomorrow.

The four arrangements, from weakest to strongest

1. A plain URL on a server

tokenURI returns https://api.someproject.io/token/412. Whoever controls that domain controls what your token is. They can change the traits, replace the picture, or let the domain lapse and take the entire collection blank at once. This is more common than anyone likes to admit, including in collections that were expensive.

2. A content hash on IPFS

tokenURI returns ipfs://bafy…. The identifier is a hash of the content, so the mapping from address to bytes cannot be changed — a different picture produces a different address, and the old address still names the old picture.

That is a real guarantee, and it is narrower than it sounds: content addressing guarantees integrity, not availability. IPFS does not store anything for you. If every node that pinned those bytes stops pinning them, the hash still correctly identifies content that nobody has. The collection does not change — it disappears.

3. Permanent storage

Arweave and similar systems take payment once and undertake to keep the data available for a very long time, with the storage cost endowed up front rather than billed monthly. This closes the availability gap that IPFS leaves open, at the price of trusting a different economic model.

4. Fully on-chain

The image itself is stored in contract storage, usually as SVG generated by the contract. Then the picture has exactly the same durability as the ownership record, because it is part of the same record.

This is the only arrangement where "immutable" needs no footnote. It is also expensive, and it constrains what the art can be, which is why it is mostly used by generative and text-based work.

The part that surprises people

Even a collection pinned properly on IPFS is usually not immutable, because the pointer is separate from the thing it points at.

Most contracts store a base URI and build each token's URI from it, and most of them include a function that lets the owner set a new base URI. That function exists for good reasons — reveals, fixing a bad batch, migrating gateways — and it means the owner can repoint every token in the collection at completely different content in one transaction.

A collection is only as immutable as the weakest of three things: the storage, the pointer, and whoever can change the pointer.

How to check, in about two minutes

  1. On a block explorer, call tokenURI with any token id. Read the scheme: https:// is a server, ipfs:// is content-addressed, data: is on-chain.
  2. In the contract's verified source, search for setBaseURI, setTokenURI, or anything similar. If one exists and is restricted to the owner, the metadata is mutable by that owner. Note whether ownership has been renounced or moved to a timelock.
  3. If it is IPFS, ask who pins it. A project that has thought about this can name its pinning service and usually has more than one. A project that has not will not understand the question.
Immutable is not a property of blockchains. It is a property of a specific arrangement, and most collections have not made it.

What to do with this

If you are buying, treat metadata durability as part of what you are paying for, and price a server-hosted collection accordingly.

If you are building, the honest options are permanent storage or on-chain, and the honest thing to say about anything else is the truth: that the art is hosted, that you can change it, and what would have to happen for it to go away. Collections that said this plainly at mint have aged far better than collections that used the word immutable and hoped nobody would check.