A commit-reveal scheme is a two-phase cryptographic protocol that allows a participant to commit to a value (like a bid, vote, or random number) by publishing a cryptographic hash of it, and later reveal the original value to prove their commitment was made in good faith. The core property is binding—the committer cannot change the revealed value—and hiding—the commitment reveals nothing about the original data until the reveal. This mechanism is fundamental for preventing front-running and information leakage in transparent systems like blockchains, where all data is public. By separating the act of deciding from the act of disclosing, it enforces a fair ordering of actions.
LABS
Glossary
Commit-Reveal Scheme
A commit-reveal scheme is a two-phase protocol where a participant first commits to a value by publishing its cryptographic hash, then later reveals the original value to prove consistency.
Chainscore © 2026
definition
CRYPTOGRAPHIC PRIMITIVE
What is a Commit-Reveal Scheme?
A commit-reveal scheme is a two-phase cryptographic protocol designed to conceal information during a commitment phase and later prove its authenticity during a reveal phase, preventing front-running and ensuring fairness in decentralized systems.
The protocol operates in two distinct phases. In the commit phase, a user generates a secret value (the preimage), often combined with a random salt to prevent brute-force attacks, and calculates its cryptographic hash (e.g., keccak256). This hash, or commitment, is broadcast to the network and recorded on-chain. In the subsequent reveal phase, which occurs after a predetermined deadline, the user must submit the original secret value and salt. The network verifies the reveal by hashing the provided data and checking it matches the earlier commitment. If it matches, the action is valid; if not, or if no reveal is made, the commitment is forfeited.
In blockchain applications, commit-reveal schemes are critical for applications requiring secrecy and verifiable fairness. A canonical example is a sealed-bid auction on-chain, where bidders commit hashes of their bids to prevent others from seeing and outbidding them. Other use cases include fair random number generation (where multiple parties commit random seeds), privacy-preserving voting, and mitigating Maximal Extractable Value (MEV) in decentralized exchanges by hiding transaction details until they are included in a block. The scheme's security relies on the cryptographic properties of the hash function, making it computationally infeasible to find a different preimage that produces the same commitment hash.
While powerful, commit-reveal schemes have practical limitations. They require two transactions (commit and reveal), doubling gas costs and user effort. The need to store commitments on-chain can also lead to state bloat. Furthermore, the scheme does not protect against collusion between participants or a party who refuses to reveal, potentially stalling a process. To address the 'no reveal' problem, many implementations incorporate deposits or slashing conditions that penalize users who fail to complete the reveal phase, ensuring economic incentives align with protocol honesty.
how-it-works
CRYPTOGRAPHIC PRIMITIVE
How a Commit-Reveal Scheme Works
A commit-reveal scheme is a two-phase cryptographic protocol that prevents front-running and ensures fairness in decentralized systems by separating the submission of information from its disclosure.
A commit-reveal scheme is a two-phase cryptographic protocol designed to ensure fairness and prevent front-running by hiding sensitive information until a predetermined time. In the commit phase, a participant generates a cryptographic hash, known as a commitment, from their secret data (like a bid, vote, or random number) and broadcasts this hash to the network. This hash acts as a sealed, tamper-proof envelope—it binds the participant to their secret without revealing it. The commitment is typically created by hashing the secret data combined with a random salt or nonce to prevent brute-force guessing of simple inputs.
After all participants have submitted their commitments, the protocol enters the reveal phase. Here, participants must publicly disclose their original secret data and the salt used. The network can then verify the revelation by re-hashing the provided data; if it matches the original commitment, the reveal is valid. This mechanism ensures that no one can change their submitted information after seeing others' data, as the initial commitment cryptographically locks in their choice. This property is crucial for applications like sealed-bid auctions, fair randomness generation (e.g., for blockchain oracles or gaming), and on-chain voting, where the order or timing of information disclosure could be exploited.
The security of the scheme hinges on the properties of the cryptographic hash function: hiding (the commitment reveals nothing about the secret) and binding (it is computationally infeasible to find a different secret that produces the same commitment). A common implementation pattern in smart contracts involves two separate transaction calls: commit(bytes32 commitment) and reveal(uint256 secret, bytes32 salt). Participants must pay gas fees twice, and the contract logic enforces that reveals are only accepted after a specific block height and that each commitment can only be revealed once by its original sender.
While effective, commit-reveal schemes introduce complexity, such as requiring participants to be online for both phases and manage their salts securely. They also incur higher transaction costs and can be vulnerable to griefing attacks where a participant commits but never reveals, potentially stalling the process. To mitigate this, many implementations incorporate deposits that are slashed for non-revelation or use timelocks to automatically proceed after a deadline. These schemes are a foundational tool for achieving fairness and transparency in decentralized applications where trust between parties cannot be assumed.
key-features
MECHANISM BREAKDOWN
Key Features of Commit-Reveal
The commit-reveal scheme is a cryptographic two-phase protocol that prevents front-running and ensures fairness by hiding information until a predetermined deadline.
01
Two-Phase Protocol
The scheme operates in two distinct, time-bound phases:
- Commit Phase: Participants submit a cryptographic hash (the commitment) of their secret data (e.g., a bid, vote, or random number). This hash acts as a sealed, unchangeable promise.
- Reveal Phase: After the commit period ends, participants must submit their original secret data. The system verifies it matches the earlier hash. Submissions failing this check are invalidated.
02
Cryptographic Binding & Hiding
The scheme relies on the one-way properties of cryptographic hash functions like SHA-256 or Keccak.
- Binding: Once a commitment is made, the participant cannot change the revealed value without detection, as it would produce a different hash.
- Hiding: The commitment hash reveals no information about the original secret data, keeping it confidential during the commit phase. This is typically achieved by hashing the secret with a random salt (nonce).
03
Prevention of Front-Running
This is a primary application in decentralized systems. By hiding transaction details (like price in a decentralized exchange auction) until the reveal phase, the scheme prevents malicious actors from observing pending transactions and front-running them with higher gas fees. All commitments are effectively submitted simultaneously from the network's perspective.
04
Fair Random Number Generation (RNG)
Commit-reveal is foundational for on-chain randomness. Multiple participants commit hashes of secret numbers. After all commitments are locked in, they reveal their numbers. The final random value is a function (e.g., XOR) of all revealed secrets. This prevents any last-mover advantage, as no participant can bias the outcome after seeing others' reveals.
05
Voting and Auctions
The scheme ensures secrecy and integrity in processes like:
- Private Voting: Voters commit to their choice, preventing coercion based on early results. Votes are only tallied after the reveal phase.
- Blind Auctions: Bidders commit to their bid amount. No one knows the bids during the commit phase, eliminating strategic bidding based on others' offers. The highest valid revealed bid wins.
06
Implementation Considerations
Key practical challenges include:
- Gas Costs: Requires two transactions (commit and reveal), doubling gas fees for participants.
- Reveal Incentives: Systems must incentivize or penalize users to complete the reveal phase; unrevealed commitments can stall processes.
- Timing Attacks: The sequence of reveal transactions can sometimes leak information, mitigated by using a reveal deadline instead of a specific order.
examples
COMMIT-REVEAL SCHEME
Examples & Use Cases
The commit-reveal scheme is a cryptographic two-step process used to ensure fairness and prevent front-running in transparent systems. Below are key applications where this mechanism is critical.
02
Random Number Generation (RNG)
Essential for creating provably fair randomness in blockchain applications like gaming and lotteries. Multiple participants each commit a secret random number. After all commits are locked in, they reveal their numbers. The final random value is a function (e.g., XOR) of all revealed secrets.
- Prevents manipulation: No single party can bias the outcome after seeing others' inputs.
- Transparent verification: Anyone can verify the final result against the committed hashes.
- Common in: NFT minting mechanics, gaming dApps, and validator selection.
05
Password & Secret Recovery
A foundational concept for secure authentication without exposing secrets. A client hashes a password (commit) and sends it to a server for storage. Later, during login, the client sends the actual password (reveal), and the server hashes it to verify it matches the stored commitment.
- Prevents exposure: The secret is never transmitted or stored in plaintext.
- Basis for: Zero-knowledge proofs and secure multi-party computation (MPC) protocols, where parties commit to private inputs before a joint computation.
06
Limitations & Practical Considerations
While powerful, commit-reveal schemes have inherent trade-offs that affect their design:
- Reveal Incentives: Systems must ensure participants have an incentive to complete the reveal phase; otherwise, transactions can fail.
- Gas Costs: Requires two transactions (commit and reveal), doubling gas fees for users.
- Latency: Introduces a delay between commitment and execution, unsuitable for real-time applications.
- Data Availability: All committed data must eventually be published on-chain for verification, increasing blockchain bloat.
SUBMISSION SCHEME COMPARISON
Commit-Reveal vs. Alternative Submission Methods
A comparison of mechanisms for submitting sensitive data, such as bids, votes, or random numbers, to a public blockchain.
| Feature / Characteristic | Commit-Reveal Scheme | Trusted Execution Environment (TEE) | Zero-Knowledge Proof (ZKP) |
|---|---|---|---|
Core Principle | Two-phase submission: hash commitment, then data reveal. | Compute within a secure, isolated hardware enclave. | Generate a cryptographic proof of valid data without revealing it. |
Data Privacy During Submission | |||
On-Chain Data Finality | After reveal phase. | Immediate (encrypted output). | Immediate (proof verification). |
Requires Trusted Third Party | |||
Cryptographic Assumptions | Collision-resistant hash functions. | Hardware integrity (e.g., Intel SGX). | Mathematical security of proof system. |
Latency Overhead | High (two transactions, waiting period). | Low (single transaction). | High (proof generation time). |
Computational Overhead | Low | Medium (enclave overhead). | Very High (proof generation). |
Primary Use Cases | Sealed-bid auctions, fair randomness. | Private smart contracts, confidential computing. | Private transactions, verifiable computation. |
security-considerations
COMMIT-REVEAL SCHEME
Security Considerations & Limitations
While a powerful tool for privacy and fairness, the commit-reveal scheme introduces specific security trade-offs and operational constraints that developers must account for.
01
Front-Running & Timing Attacks
The scheme's two-phase nature creates a window for manipulation. Malicious actors can monitor the commitment phase on-chain, then front-run the reveal phase by submitting their own transaction with a higher gas fee to claim an advantage. This is a critical risk in applications like decentralized exchanges or NFT mints where order matters. Mitigations include using cryptographic salts and enforcing strict, short reveal periods.
02
Data Availability & Storage Cost
Storing commitments on-chain, even as hashes, incurs gas costs. For high-frequency applications, this can be prohibitively expensive. Furthermore, the reveal data (the original preimage) must be reliably broadcast and included in a block; network congestion or miner censorship can cause valid reveals to fail. This makes the scheme unsuitable for real-time, low-latency operations without careful fee management and incentive design.
03
Collusion & Sybil Attacks
In voting or random number generation, participants may collude during the reveal phase to bias the outcome. A Sybil attack, where one entity controls multiple identities, can be particularly damaging if the commit phase has no cost or identity proof. Defenses include requiring staked collateral (slashed for non-revelation), using verifiable random functions (VRFs), or implementing decentralized identity solutions to limit influence.
04
Cryptographic Assumptions & Weaknesses
The scheme's security rests entirely on the properties of the cryptographic hash function (e.g., SHA-256, Keccak). It assumes the function is preimage-resistant (cannot reverse the hash) and collision-resistant (cannot find two inputs with the same hash). A breakthrough in cryptanalysis or the advent of quantum computing could theoretically break these assumptions, compromising all pending commitments. Using robust, future-resistant hash functions is essential.
05
User Experience & Complexity
From a UX perspective, requiring users to make two transactions (commit and reveal) doubles the interaction cost and complexity. Users must securely store their secret and the corresponding salt between phases, which can lead to loss of funds or voting power if forgotten. This friction limits adoption for consumer-facing dApps and necessitates robust wallet integration and clear user education to prevent errors.
06
Blockchain-Specific Limitations
The scheme's effectiveness varies by consensus mechanism. On Proof-of-Work chains, miners have significant control over transaction ordering, impacting fairness. On high-throughput chains, the reveal window must be calibrated to chain finality times. Layer 2 solutions and private mempools can also interfere with the scheme's transparency assumptions. Design must be tailored to the specific execution environment's guarantees and constraints.
code-example
COMMIT-REVEAL SCHEME
Code Example (Pseudocode)
A practical pseudocode implementation demonstrating the two-phase cryptographic protocol used to conceal information until a predetermined time.
The commit-reveal scheme is a cryptographic protocol executed in two distinct phases to ensure fairness and prevent front-running. In the commit phase, a user generates a cryptographic commitment—typically a hash of their secret data combined with a random salt—and publishes only this hash to the network. This hash acts as a sealed envelope, binding the user to their secret without disclosing it. The commitment is stored on-chain, often within a smart contract, locking in the user's intent. This phase prevents other participants from seeing and copying the original data, a critical defense against manipulation in scenarios like auctions or random number generation.
After a predetermined period, the reveal phase begins. Here, the original participant must publish the original secret data and the salt used to create the commitment. The smart contract or verifying party then re-computes the hash of the revealed data. If the result matches the originally published commitment hash, the reveal is validated as authentic and the protocol proceeds. If the participant fails to reveal, or reveals incorrect data, they may forfeit a stake or be excluded. This mechanism ensures that the initial commitment was made in good faith and that the final outcome is derived from the originally intended, but temporarily hidden, information.
A common application is in on-chain auctions or voting, where users must submit bids or votes without others seeing them first. For example, in a blind auction, all bidders submit hashed bids during the commit phase. After the commit window closes, they reveal their actual bid amounts. The highest revealed bid wins, but no one could adjust their bid based on others' information. The random salt is crucial; without it, simple values like bid amounts could be easily guessed and brute-forced, undermining the scheme's security. The salt ensures the commitment is a unique, non-deterministic hash.
Implementing this requires careful smart contract design to manage phases, track commitments, handle reveals, and penalize non-compliance. The contract must enforce timing constraints, store a mapping of commitments (e.g., commitments[user] = hash), and provide functions for commit(bytes32 hash) and reveal(uint value, bytes32 salt). Gas costs are incurred twice, and the scheme introduces latency due to the waiting period between phases. However, this trade-off is essential for achieving fairness and resistance to front-running in transparent, decentralized environments where all data is public.
COMMIT-REVEAL SCHEME
Common Misconceptions
Clarifying frequent misunderstandings about the cryptographic technique used to hide information on a transparent blockchain.
No, a commit-reveal scheme is not encryption; it is a cryptographic commitment scheme that uses a hash function to create a binding and hiding promise of data. The commit phase involves publishing a hash (e.g., keccak256(value, salt)) to the blockchain, which acts as a sealed envelope. The reveal phase later publishes the original data and salt, allowing anyone to verify the hash matches. Unlike encryption, the hash is a one-way function—you cannot derive the original data from the commitment, only confirm it after the reveal. This makes it ideal for applications like sealed-bid auctions or random number generation on-chain, where data must be provably hidden until a specific time.
COMMIT-REVEAL SCHEME
Frequently Asked Questions
A commit-reveal scheme is a cryptographic protocol used to ensure fairness and prevent front-running in blockchain applications by submitting information in two phases. Below are common questions about its mechanics and use cases.
A commit-reveal scheme is a two-phase cryptographic protocol designed to submit sensitive information, like a bid or a vote, without revealing it prematurely. In the commit phase, a user submits a cryptographic commitment, typically a hash of their secret data combined with a random salt. Later, in the reveal phase, the user submits the original data and salt, allowing the network to verify it matches the earlier hash. This prevents other participants from seeing and copying the information during the initial submission, ensuring fairness in processes like auctions or governance voting.
ENQUIRY
Get In Touch
today.
Our experts will offer a free quote and a 30min call to discuss your project.
NDA Protected
Confidentiality24h Response
Time to ValueDirectly to Engineering Team
No Sales Fluff10+
Protocols Shipped
$20M+
TVL Overall