The NFT Reveal Process Explained: What Changes and When

2026-09-03

You mint, and every token in the collection shows the same grey placeholder. A day later the artwork appears and a rarity site tells you what you are holding. Your token did not move in between, and nothing was added to it. A reveal is one string changing at the contract, plus an assignment that was decided before anyone could see the result.

The NFT Reveal Process Explained: What Changes and When: key points at a glance

What a reveal changes

An NFT is an id that a smart contract records against an owner address. The name, the description, and the artwork are not part of that record.

The ERC-721 token standard puts them behind one function. Given a token id, tokenURI returns a Uniform Resource Identifier, and the specification adds that the URI may point to a JSON file that conforms to the ERC721 Metadata JSON Schema. Everything a gallery draws comes from the far end of that pointer.

Before a reveal, that function returns the same placeholder document for every id in the collection. After it, each id resolves to its own document. That is the whole event: the string the contract hands back changes, and the documents at the far end start differing per id where they did not before.

Nothing else about your token changes. The id is the same, the owner is the same, the transfer history is the same, and you sign nothing. A reveal is something the collection does, not something your token undergoes.

Why a collection sells before it shows

If the artwork were visible while the sale was running, buyers could read the map from id to artwork and buy only the ids worth buying. Minting would turn into a contest to grab particular ids, and the rest of the collection would sit unsold.

A blind sale removes that option by removing the information. Every buyer takes the same unknown, and the map is published only once the sale can no longer be steered by it. The delay is therefore deliberate rather than a technical necessity, which is why a collection can sit unrevealed for days without anything being wrong.

The two decisions a reveal is made of

A reveal is two separable things that get merged in conversation. One is the assignment: which metadata entry belongs to which token id. The other is the switch: when the contract starts returning per-id documents instead of the placeholder.

The switch is a transaction anyone can see. The assignment is a rule fixed in advance, and it is where the fairness question actually lives. A collection can flip the switch in plain view and still have chosen the assignment after watching who bought which id, so the visible half of the process is not the half that needs checking.

The switch is one owner transaction

In a contract that serves the placeholder by returning a fixed URI, revealing means the account holding owner privileges calls a setter that changes the base URI the contract builds its answers from. One transaction, and every id in the collection resolves somewhere new.

That lever is the same one that decides whether metadata is frozen. As long as an account can point the collection somewhere else, it can point it somewhere else again after the reveal. Revealed and frozen are two different claims, and the first does not imply the second.

The assignment is one offset

Assigning artwork one id at a time would take a transaction per id. One number does the job instead: a starting index, drawn once, applied to the whole collection.

Take a collection of 10,000 tokens and a metadata set numbered in a fixed published order. Draw a starting index of 3,142, and the rule is that token id one takes metadata entry 3,143 and the sequence wraps around the end of the list, so id 6,859 takes the entry back at the top.

One number therefore fixes the entire map. Nobody has to trust that ten thousand assignments were each made honestly, because there is only one draw to reason about, and once it is recorded on chain it cannot be redrawn quietly.

Committing to the artwork before anyone sees it

The offset shuffles a list. It says nothing about whether the list itself was fixed in advance, and a collection able to edit the list after the draw could still put the desirable artwork wherever it wanted.

A provenance hash closes that half. The images are hashed in their published order, the hashes are joined, and the result is hashed once more and published before the sale opens. After the reveal anyone can repeat those steps on the revealed files and compare. A match says the set and its order are the ones committed to, and a mismatch says something moved.

Read the two claims separately. The provenance hash covers what was in the list. The starting index covers where the list was cut. Publishing one and not the other leaves the other half unproven, which is worth checking before a mint rather than after.

Where the offset comes from

The draw has to be unpredictable while the sale is running and verifiable once it is over. Those two requirements are what make the source of the number the interesting part rather than a detail.

Deriving it inside the contract from block data is the cheap route, and its weakness is that block data is produced by a party that can see the transaction and has some control over it. A verifiable randomness service takes the other route: the value arrives with a proof that it was generated from a committed key and the request, so the contract can check the proof before accepting the number.

A third pattern sidesteps the timing question by not assigning anything until the last token is sold, so the draw cannot be timed against a position the seller still holds.

When a reveal looks stuck

What you see	What is going on underneath	What changes it
Every token still shows one placeholder	The contract still returns the pre-reveal URI	The collection flipping the switch
Others revealed, your tile did not	The platform is serving an older cached copy	A refresh on that platform
Artwork appeared, traits are missing	The document loaded, the attributes did not	Another read once the document is complete
Traits differ from what a rarity site shows	Two tools scored the same traits differently	Nothing, because they answer different questions

The first two rows get read as the same problem, and they are not. The first is a statement about the chain, and no amount of reloading moves it. The second is a statement about one platform's stored copy, and asking that platform for a metadata refresh is the instruction that clears it.

Check the contract before deciding which one you are looking at. Reading tokenURI for your id on a block explorer returns the on-chain answer, and if that answer is still the placeholder, the reveal has not happened for anyone.

What a reveal does not decide

Rarity is not created at the reveal. It was fixed when the metadata set was built and the offset was drawn, and the reveal only makes it readable. A token does not become scarce because a site started displaying it.

The reveal also does not settle what rare means. Counting how unusual each trait is and scoring a whole token are different operations, which is why two tools can rank the same revealed collection differently, and trait rarity is one method among several rather than the answer.

And it does not lock anything down. The reveal points the collection at new documents. Whether those documents can be changed afterwards depends on where they live and on who still holds the key that sets the pointer.

The bottom line

A reveal is a pointer change plus a map that was decided beforehand. The pointer change is public and easy to verify. The map is where the commitments are: a provenance hash published before the sale fixes what is in the list, and a starting index drawn from a source nobody could steer fixes where the list was cut.

Before a mint, look for both of those in writing, and check whether the account that flips the switch can flip it again afterwards. After a mint, separate a collection that has not revealed from a platform that has not caught up, because only one of the two is yours to act on. To keep learning the fundamentals, follow more from Bitbase Academy.