Reveal Mechanism

The core cryptographic pattern where a user first publishes a commitment (a hash of the secret data) to the blockchain. Later, they reveal the original data, allowing anyone to verify it matches the earlier commitment. This creates a binding promise that cannot be altered.

• Prevents Front-Running: Miners or other users cannot copy or preempt the action after seeing the secret.
• Ensures Fairness: All participants commit their secrets before any are revealed, creating a level playing field.

A primary application where a verifiable random function (VRF) or similar oracle generates a random seed. The seed's commitment is stored on-chain first, with the actual random number revealed later in a separate transaction. This prevents the generator from manipulating the outcome after seeing bets or user inputs.

• Use Case: NFT trait generation, gaming loot boxes, and validator selection in proof-of-stake networks.
• Example: Chainlink VRF provides this as a service, generating a random number and cryptographic proof that is verified on-chain upon reveal.

Used in auctions (e.g., NFT or domain name sales) to prevent bid sniping. Participants submit a hashed version of their bid amount during the commit phase. In the reveal phase, they disclose the actual bid, which is checked against the hash. Only bids that match a valid commitment are accepted.

• Key Benefit: Bidders cannot see others' bids and adjust their own in real-time, leading to more honest price discovery.
• Process: Commit phase → Reveal phase → Winner determination and settlement.

A cryptographic salt (random number) is combined with the secret data before hashing to create the commitment. This prevents brute-force attacks where an attacker could guess simple secrets (like a single number) by hashing all possibilities.

• Function: commitment = hash(secret + salt).
• Reveal Requirement: Both the original secret and the salt must be disclosed for verification.
• Prevents Preimage Attacks: Makes it computationally infeasible to find an input that generates a given hash output.

Smart contracts enforce strict time windows for the commit and reveal phases. A commit period is followed by a reveal period. Actions are only valid if the reveal transaction occurs within the designated window after the commit.

• Purpose: Prevents indefinite withholding of secrets, which could stall the protocol.
• Consequence: Funds or bids associated with an unrevealed commitment are often forfeited after the deadline, penalizing non-participation.

Reveal mechanisms often split logic across two transactions, which has gas implications. The commit transaction is typically cheap (stores only a hash). The reveal transaction is more expensive as it performs computation and state changes.

• Optimization: Protocols may batch multiple reveals into a single transaction.
• User Burden: Users must ensure they have funds for the second transaction; failure to reveal can result in loss of funds or participation rights.

In NFT collections, a reveal mechanism is used to conceal the final artwork until after the minting process is complete. This creates anticipation and prevents sniping of rare traits.

• Process: Buyers mint a placeholder token (e.g., a generic image). After minting concludes, the project executes a transaction to reveal the unique metadata and image for each token.
• Example: Popular collections like Bored Ape Yacht Club and CryptoPunks initially used this method, with the final traits revealed after all tokens were minted.

A commit-reveal scheme uses a two-phase reveal mechanism to ensure vote privacy and prevent strategic manipulation in on-chain governance.

• Commit Phase: Voters submit a cryptographic hash of their vote (a commitment).
• Reveal Phase: Voters later submit their original vote to be matched against the hash. The final tally is only calculated after all votes are revealed.
• Purpose: This prevents voters from seeing early results and changing their votes, ensuring a fair outcome. It's a foundational pattern in DAO governance.

Reveal mechanisms are essential for generating provably fair random numbers on-chain, which are used in gaming and lotteries.

• Process: Multiple participants submit commitments (hashes of secret numbers). After all commitments are locked, they reveal their secrets. The final random seed is derived from the combination of all revealed values.
• Security: This prevents any single party from predicting or manipulating the outcome, as they cannot know others' values before revealing their own. Used by protocols like Chainlink VRF.

In blockchain auctions, a reveal mechanism enables sealed-bid auctions where bids are kept secret until a designated reveal phase.

• Workflow: Bidders submit a commitment (hash of bid amount + secret). After the bidding period ends, a reveal phase opens where bidders must disclose their actual bid. Only bids with a valid commitment are accepted.
• Advantage: This prevents front-running and bid sniping, as no one knows the competing bids during the initial submission. Common in NFT platforms and decentralized marketplaces.

In Optimistic Rollups, a reveal-like mechanism is part of the fraud proof challenge period.

• Process: After a state root is proposed on L1, there is a challenge window (e.g., 7 days) where any watcher can "reveal" fraud by submitting a fraud proof.
• Function: This delay acts as a mandatory reveal period for invalid transactions. If no fraud is revealed, the state is finalized. This mechanism ensures security while allowing for low-cost transactions.

Reveal mechanisms underpin cryptographic protocols like Secret Sharing and Secure Multi-Party Computation (MPC).

• Concept: A secret (e.g., a private key) is split into shares distributed among participants. The original secret can only be revealed (reconstructed) when a sufficient number of parties combine their shares.
• Use Case: This is used in threshold signatures for wallet security and cross-chain bridges, where the signing key is never fully assembled in one place until the authorized reveal event.

The core cryptographic pattern underpinning most reveal mechanisms. It involves two phases:

• Commit: Users submit a cryptographic hash (commitment) of their hidden data (e.g., a token URI or bid amount).
• Reveal: Later, users submit the original data. The system verifies it matches the earlier hash. This prevents front-running and ensures the revealed data cannot be changed after the commitment, providing tamper-evident fairness.

Defines where the critical reveal data is stored and verified.

• On-Chain Reveal: The final metadata (e.g., image hash, traits) is stored directly on the blockchain after the reveal. This provides maximum transparency and immutability but at higher gas costs.
• Off-Chain Reveal: Only a reference (like an IPFS CID) is stored on-chain, with the actual metadata hosted on decentralized storage. Trust shifts to the integrity of the storage layer and the honesty of the project in not altering the files post-reveal.

Critical for fair NFT trait distribution. A provenance hash is the keccak256 hash of the final, ordered metadata list (e.g., all NFT traits in their final mint order). This hash is published before the reveal. After the reveal, anyone can verify that the revealed metadata, when hashed in order, matches the published provenance hash. This cryptographically proves the project did not manipulate traits based on early mint activity, ensuring verifiable randomness.

During the gap between mint (commit) and reveal, users must trust that:

• The project will execute the reveal transaction as promised.
• The off-chain metadata (if used) is already finalized and matches the provenance hash.
• The randomization seed (if used) was generated fairly and not manipulated. Breach of these assumptions is a central risk, making the reputation of the project team a key factor.

Reveal mechanisms are a primary defense against market manipulation. In NFT auctions or minting:

• Without a commit phase, an attacker could see a favorable reveal (e.g., a rare trait) and outbid others at the last second (sniping).
• The commit phase hides the final value, forcing all participants to act on incomplete information. This levels the playing field and is a cornerstone of cryptographic fairness in decentralized systems.

Common vulnerabilities in reveal mechanism code include:

• Lack of Finalization: Allowing the project to change the provenance hash or metadata after a commitment.
• Weak Randomness: Using a seed like block.timestamp or blockhash that miners/validators can influence.
• Gas Griefing: Designing a reveal function that can be made prohibitively expensive for users to call.
• Centralized Trigger: Relying on a single admin wallet to initiate the reveal, creating a single point of failure.

In on-chain gaming and lotteries, the reveal mechanism is the final, on-chain event where a previously generated or committed random seed is disclosed to determine winners. This decouples the betting period from the outcome determination, preventing last-block manipulation.

• Typical Flow: 1) Commit phase (hash of seed is stored). 2) User interaction period (bets placed). 3) Reveal phase (seed is published, outcomes are calculated).
• Security Goal: Guarantees the house or players cannot influence the result after bets are locked.

In zero-knowledge proof systems, the reveal is the act of a prover submitting a succinct proof to the verifier. While the underlying witness data remains hidden, the proof itself is revealed to demonstrate knowledge or truth of a statement.

• Contrast with Commit-Reveal: ZK proofs reveal that a statement is true without revealing why, whereas commit-reveal schemes eventually reveal the full underlying data.
• Primary Function: Enables privacy-preserving transactions and computations, as seen in zkRollups and private payment systems.

Decentralized oracles like Chainlink employ a reveal mechanism when responding to data requests. A node first commits an off-chain data point, and later reveals it on-chain along with a signature. The reveal triggers the aggregation of multiple responses and the settlement of the requested value in a smart contract.

• Process: Commit (report hash), Reveal (submit data and signature), Aggregate (consensus layer validates).
• Purpose: Provides a secure bridge for external data, ensuring data cannot be altered between the time it's fetched and the time it's used on-chain.

A classic application of the commit-reveal scheme. Bidders submit a cryptographic commitment of their bid amount. After the bidding period closes, the reveal phase begins, where bidders disclose their actual bids. Only bids that match a valid commitment are accepted, and the highest revealed bid wins.

• Advantage: Prevents bid sniping, as no one knows others' bids during the commitment phase.
• On-Chain Example: Early implementations were used in Ethereum's BlindAuction smart contract example.