Delayed Reveal

The process begins with a cryptographic commitment, where the creator generates a hash of the final metadata (including the image URL) and stores it on-chain before the mint. This hash acts as a provable, immutable promise of the content. The actual image files are hosted off-chain (e.g., on IPFS or Arweave) but remain inaccessible until the reveal event. This ensures the final artwork cannot be deduced or altered after the commitment is made.

The reveal is triggered by a specific on-chain transaction, often initiated by the project team after the mint concludes. This transaction publishes the provenance hash and the key to decrypt or access the final metadata. Smart contracts then use this data to update the tokenURI for each token, permanently linking it to its specific, randomly assigned artwork. The process is typically automated and batched for all tokens in the collection simultaneously.

A primary purpose is to prevent rarity sniping, where bots or informed users mint only tokens predicted to have rare traits. By keeping the final assignment secret until after all mints are complete, every mint is a blind purchase with equal probability of receiving any trait. This enforces a fair, random distribution and protects the secondary market from initial manipulation based on insider knowledge of rarity.

The provenance hash is a critical, on-chain record (often a SHA-256 hash) that cryptographically commits to the final ordered list of token metadata or artwork. It is published before the mint starts. After the reveal, anyone can verify that the revealed artworks match this hash, proving the team did not manipulate the distribution after seeing mint activity. This provides verifiable fairness and trustlessness to the process.

Before the reveal, all tokens point to identical placeholder metadata. This is typically a generic image (e.g., a mystery box or uniform cover) and metadata describing the collection rather than individual traits. The placeholder URI is often stored in the smart contract and is replaced en masse during the reveal event. This creates a unified pre-reveal experience for all holders.

• Centralized Reveal: The team controls the reveal transaction, often using a multi-sig wallet for security.
• Randomized Assignment: Token IDs are mapped to final metadata via a verifiably random function (VRF) or a pre-committed shuffled list.
• Gas Considerations: Reveal transactions can be gas-intensive as they update state for many tokens, a cost often borne by the project.
• Reveal Phasing: Large collections may reveal in phases to manage server load and gas costs.

Prevents front-running and gas wars by ensuring all participants mint a generic placeholder (e.g., a 'mystery box') before the final art is revealed. This creates a level playing field where no one knows which specific asset they will receive until after the mint concludes.

• Key Benefit: Mitigates sniping where bots target rare traits.
• Example: A 10,000-piece PFP collection where all minters receive identical 'Unrevealed Ape' NFTs that later transform into unique characters.

The period between mint and reveal builds anticipation, driving social media discussion and speculation. Creators can use this window for reveal countdowns, trait teasers, and community events.

• Mechanism: The provenance hash is often published upfront, providing a cryptographic commitment to the final set without leaking details.
• Marketing Tool: Turns the mint into a multi-stage event, sustaining interest beyond the initial sale.

Ensures the final assignment of traits to token IDs is provably random and cannot be manipulated by the creator post-mint. This is typically achieved using a commit-reveal scheme.

• Process: The creator commits a seed (like a hash of the final metadata ordering) to the smart contract before the mint. After minting ends, the seed is revealed to trigger the final assignment.
• Trust Model: The committed hash allows the community to verify that the revealed metadata matches the original, unchangeable plan.

The placeholder NFT points to a generic image and metadata file. After the reveal, the contract's baseURI or tokenURI function is updated to point to the final folder containing the unique metadata for each token ID.

• Storage: Final images and metadata are often pre-uploaded to decentralized storage like IPFS or Arweave but kept hidden until the reveal transaction.
• Smart Contract Function: A reveal() function is called by the project admin to update the metadata endpoint for the entire collection.

Directly translates the 'loot box' model to blockchain, where users purchase an unopened digital item. The reveal is the act of opening the box to discover its contents, which could be a character, weapon, or other in-game asset.

• Dynamic NFTs: The NFT's visual representation and attributes change post-reveal based on the randomized outcome.
• Utility Focus: The value is in the utility of the revealed asset within a game or ecosystem, not just its art.

A specific security application where delayed reveal stops automated bots from identifying and minting only the rarest NFTs in a collection during the live sale. Since all metadata is hidden, bots cannot selectively target specific token IDs.

• Problem Solved: Without delayed reveal, bots can monitor mint transactions and simulate rarity calculations to snipe high-value assets.
• Result: Human participants have a significantly higher chance of obtaining a rare item, improving perceived fairness.

The process is executed in two distinct on-chain phases.

• Phase 1: Minting & Commitment: Users mint tokens that initially share a common placeholder image and metadata (e.g., 'Unrevealed #1'). The final tokenURI for each token is pre-calculated but its hash is stored on-chain, committing to the final asset without revealing it.
• Phase 2: Reveal & Finalization: The project admin triggers a transaction to update the baseURI or tokenURI for the entire collection, pointing to the final, unique metadata. The pre-committed hashes are verified to ensure the reveal matches the original commitment.

Fairness is cryptographically guaranteed by committing to the final metadata before the mint.

• The final metadata for each token ID is generated and stored off-chain.
• A cryptographic hash (e.g., keccak256) of the final tokenURI for each token is computed.
• This hash, or a Merkle root of all hashes, is stored in the smart contract's immutable storage during deployment or before minting begins.
• After the reveal, anyone can verify that the revealed metadata hashes to the pre-committed value, proving the outcome was not manipulated post-mint.

Implementation typically involves overriding the tokenURI function and managing state.

• State Variables: Contracts use a baseURI (string) and a revealed (boolean) flag, or a mapping from token ID to its final URI.
• Reveal Function: A privileged function (e.g., reveal(string memory newBaseURI)) is called by the owner to set the final baseURI and flip the revealed flag to true.
• URI Logic: The tokenURI function checks the revealed state. If false, it returns a placeholder URI. If true, it concatenates the baseURI with the token ID.
• Provenance Hash: A public variable often stores the hash of the final metadata set for independent verification.

The unrevealed and final assets are managed off-chain, requiring careful orchestration.

• Placeholder Assets: A single 'unrevealed' image and metadata file are hosted (e.g., on IPFS or a web server).
• Final Assets: The complete set of unique metadata JSON files and images are prepared and uploaded to persistent storage before mint starts. Their final URIs are deterministic.
• Provenance Record: The project publishes the provenance hash and the final IPFS CID or storage location before minting. This allows the community to verify the integrity of the unrevealed collection's size and the commitment to the final order.

The technique shifts trust to the pre-commitment and the immutability of the smart contract.

• Trust in Pre-Commitment: Users must trust that the provenance hash was generated correctly and that the team cannot change the final assets after seeing mint patterns.
• No Re-Rolls: The final mapping of token ID to asset is fixed upon commitment. The team cannot 're-roll' attributes after the mint.
• Centralization Risk: The reveal transaction is typically initiated by a privileged admin key. A compromised key or failure to call reveal could leave tokens permanently unrevealed.
• Gas Efficiency: Storing hashes is gas-efficient. A bulk reveal updates a single state variable, minimizing transaction costs compared to setting URIs individually.

A simplified view of key contract functions.

solidityCopy
contract DelayedRevealNFT is ERC721 {
    string public provenanceHash;
    string private _baseTokenURI;
    bool public revealed = false;

    constructor(string memory initialURI, string memory _provenanceHash)
        ERC721("Example", "EXP") {
        _baseTokenURI = initialURI; // Placeholder URI
        provenanceHash = _provenanceHash; // Commit to final assets
    }

    function reveal(string memory newBaseURI) external onlyOwner {
        require(!revealed, "Already revealed");
        _baseTokenURI = newBaseURI;
        revealed = true;
    }

    function tokenURI(uint256 tokenId) public view override returns (string memory) {
        require(_exists(tokenId), "Token does not exist");
        if (!revealed) {
            return _baseTokenURI;
        }
        return string(abi.encodePacked(_baseTokenURI, Strings.toString(tokenId)));
    }
}

A delayed reveal process typically involves two steps. First, a placeholder or encrypted metadata hash is stored on-chain during the initial mint. Second, after a set block height or time, the project creator submits a transaction to reveal the actual metadata, which is then permanently linked to the token IDs. This uses commit-reveal schemes to ensure the final content cannot be altered after the initial commitment.

The main security goal is to prevent rarity sniping or frontrunning. By hiding the final traits until after all tokens are minted and randomly assigned, it stops bots from selectively minting only the rarest (and most valuable) assets, ensuring a fair distribution. It also protects the project's launch mechanics from being gamed by sophisticated actors monitoring the mempool.

This model shifts trust to the project's orchestrator (the revealer). Key risks include:

• Reveal Failure: The final metadata is never published, leaving tokens with placeholder data.
• Malicious Reveal: The orchestrator could theoretically reveal different metadata than originally implied, though this is often mitigated by publishing the final IPFS hash in advance.
• Centralization: The reveal function is typically controlled by a privileged admin key, creating a single point of failure.

Common implementations store a provenance hash (a cryptographic hash of the final metadata concatenated with the final token order) on-chain before minting. After the mint, the actual metadata and the ordering are revealed. The community can then verify that the hash matches, proving the final results were not manipulated post-mint. This is a form of cryptographic commitment.

A prominent example is the Bored Ape Yacht Club mint. The team used a delayed reveal where all NFTs initially displayed the same placeholder image. After the mint concluded, a reveal transaction was executed, assigning the unique ape images to the already-minted tokens. This prevented bots from knowing which token ID corresponded to which rare trait during the sale.

• Commit-Reveal Scheme: The underlying cryptographic pattern for hiding and later proving information.
• Provenance Hash: The on-chain commitment that anchors the promised final state.
• Randomness (RNG): Often paired with delayed reveal; the final assignment of traits to token IDs uses a verifiably random seed revealed after the mint.
• Merkle Tree: Sometimes used to efficiently prove inclusion of metadata for large collections during the reveal phase.