Commit-Reveal Scheme

What Is a Commit-Reveal Scheme?

A commit-reveal scheme is a fundamental cryptographic protocol that allows a participant to lock in a choice without disclosing it, then prove that choice later. It works like placing a sealed bid in an envelope: once submitted, you cannot change your bid, but nobody can read it until envelopes are opened. In blockchain contexts, the "envelope" is a cryptographic hash, and "opening" means publishing the original data (the preimage) that produces that hash.

The scheme solves a core problem on transparent blockchains: all pending transactions are visible in the mempool before they are confirmed. Without commit-reveal, an adversary watching the mempool can see your intended action and submit a competing transaction with higher fees to get ahead of you. By splitting the action into two steps, commit-reveal ensures the intent is hidden during the critical window when front-running would be possible.

The concept originates from the broader family of commitment schemes in cryptography, which were formalized in the 1980s and have since become essential building blocks in zero-knowledge proofs, secure multi-party computation, and blockchain protocol design.

How It Works

A commit-reveal scheme operates in two distinct phases, separated by a time boundary that the protocol enforces.

Phase 1: Commit

The participant takes their secret value (a vote, a bid, a name they want to register) and combines it with a random secret called a nonce or salt. They then compute a cryptographic hash of this combined input and publish only the hash on-chain. The hash acts as a binding fingerprint: it uniquely identifies the underlying data without revealing it.

// Commit phase: hash your secret value with a random salt
commitment = keccak256(abi.encodePacked(value, salt))

// Publish commitment on-chain
contract.commit(commitment)

The salt is critical. Without it, an attacker could try hashing every possible value (a brute-force or dictionary attack) to figure out what was committed. For example, if the commitment hides a vote that can only be "yes" or "no," an attacker only needs two hash computations to break it. Adding a random 256-bit salt makes this infeasible.

Phase 2: Reveal

After the commit window closes (preventing any new commitments), the participant publishes their original value and salt. The smart contract recomputes the hash from these inputs and checks it against the stored commitment. If the hashes match, the reveal is accepted. If they differ, the participant is trying to change their answer and the reveal is rejected.

// Reveal phase: submit the original value and salt
contract.reveal(value, salt)

// Contract verifies: keccak256(value, salt) == stored commitment
// If match: accept the revealed value
// If mismatch: reject (participant tried to change their answer)

Security Properties

A properly constructed commit-reveal scheme provides two guarantees derived from the properties of the underlying hash function:

• Hiding: the commitment reveals nothing about the underlying value. Because the hash is a one-way function and includes a random salt, an observer cannot determine what was committed by inspecting the hash alone.
• Binding: once published, the commitment cannot be opened to a different value. Finding two different inputs that produce the same hash would require breaking the collision resistance of the hash function, which is computationally infeasible for algorithms like SHA-256 or Keccak-256.

Use Cases

ENS Domain Registration

The Ethereum Name Service (ENS) uses commit-reveal to prevent front-running of .eth domain registrations. If registration were a single transaction, a bot watching the mempool could see someone trying to register "valuable-name.eth" and submit the same registration with a higher gas price to claim it first.

ENS splits registration into two steps separated by a mandatory 60-second waiting period:

1. The user calls commit() with a hash of the desired name, their wallet address, and a secret generated by their browser
2. After 60 seconds, the user calls register() with the plaintext name and secret, completing the registration

During the waiting period, no observer can determine which name is being registered. By the time the name is revealed, the commitment is already recorded on-chain, so front-running the second transaction would be pointless: the original committer has priority.

Sealed-Bid Auctions

On-chain auctions benefit from commit-reveal because it enables sealed bidding. In a standard open auction on a transparent blockchain, every participant can see every other bid, encouraging last-second sniping and discouraging honest price discovery.

With commit-reveal, all bidders submit hashed bids during the commit window. Once the window closes, bidders reveal their actual amounts. Since no one can see competing bids before committing, participants are incentivized to bid their true valuation. This structure is commonly used for high-value NFT sales and domain name auctions.

On-Chain Voting

Transparent on-chain voting suffers from "herding": early voters influence later voters, and whale wallets can signal their preference to sway outcomes. Commit-reveal voting solves this by hiding individual votes until the voting period ends.

Each voter commits a hash of their vote during the voting window. After the window closes, a reveal period opens where voters publish their actual choices. The contract verifies each reveal against its commitment. This prevents vote-buying (the buyer cannot verify how someone voted during the commit phase) and eliminates tactical voting based on seeing partial results.

On-Chain Random Number Generation

Generating fair random numbers on a deterministic blockchain is notoriously difficult. Commit-reveal provides one approach: multiple participants each commit a random value, then reveal them after all commitments are recorded. The final random number is derived by combining (typically XORing or hashing together) all revealed values.

No single participant can predict the final output because it depends on everyone else's secret values. However, this approach is vulnerable to the "last-revealer" problem: the final participant to reveal can see all other values and choose whether to reveal (getting a favorable outcome) or forfeit their deposit (if the outcome is unfavorable). Protocols like Chainlink VRF address this limitation with verifiable random functions.

Relationship to Hash Time-Locked Contracts

Hash time-locked contracts (HTLCs) share the same core mechanism as commit-reveal: a hash locks a payment, and revealing the preimage unlocks it. In Lightning Network payments, the receiver generates a preimage and shares its hash in a BOLT 11 invoice. When the sender routes a payment locked to that hash, the receiver reveals the preimage to claim the funds, and this reveal propagates back through every hop in the route.

The key difference is purpose: commit-reveal schemes hide information to ensure fairness (preventing front-running, enabling sealed bids), while HTLCs use the hash-preimage pair to enforce atomic conditionality (the payment either completes everywhere or nowhere). Both rely on the same cryptographic primitive: the one-way property of hash functions that makes it easy to verify a preimage but impossible to compute one from the hash.

Atomic swaps, submarine swaps, and discreet log contracts all extend this commit-then-reveal pattern to coordinate trustless exchanges across different chains and layers.

Why It Matters

On transparent blockchains, information asymmetry creates opportunities for exploitation. Miners and validators can reorder transactions for profit (MEV), bots can front-run DEX trades, and observers can preempt domain registrations or auction bids. Commit-reveal is one of the simplest and most effective countermeasures because it removes the information advantage entirely during the critical decision window.

For Bitcoin layer-2 protocols like Spark, the commit-reveal pattern appears in the HTLC-based payment routing that enables trustless multi-hop transfers. Understanding commit-reveal helps explain why Lightning payments are atomic: the hash commitment ensures that revealing the preimage at any point in the route guarantees settlement across all hops.

Risks and Considerations

Griefing by Non-Revelation

A participant can commit but never reveal, disrupting protocols that require all commitments to be opened. In voting schemes, this means missing votes. In random number generation, it means the final result cannot be computed. Protocols mitigate this by requiring deposits that are forfeited if the reveal phase is skipped, but this introduces its own economic tradeoffs: the cost of griefing must exceed the potential benefit of withholding information.

Last-Revealer Advantage

In multi-party commit-reveal protocols (such as on-chain RNG), the last participant to reveal has an asymmetric advantage. They can see all other revealed values, compute the final outcome, and decide whether revealing benefits them. If the stake exceeds the deposit, rational actors will choose to grief. More sophisticated constructions like threshold commitment schemes or verifiable delay functions address this, but add complexity.

Front-Running the Reveal

While the commit phase is protected, the reveal transaction itself is visible in the mempool. In some protocols, an adversary who sees a reveal can extract useful information before the reveal transaction confirms. For example, in a sealed-bid auction, seeing a reveal in the mempool could theoretically allow a validator to censor or reorder it. Protocol designs must ensure that observing the reveal provides no actionable advantage, or use private mempools and encrypted mempool solutions to hide reveal transactions.

Gas Cost and User Experience

Commit-reveal requires two separate on-chain transactions instead of one, roughly doubling the gas cost and adding a mandatory waiting period. For ENS registration, this means a 60-second delay and two transaction fees. For applications targeting mainstream users, this friction can be significant. Some protocols batch commits or use off-chain commit phases to reduce overhead.

Salt Management

If a user loses their salt before the reveal phase, they cannot prove their commitment and effectively forfeit their participation. ENS stores the salt in browser local storage, which can be lost if the user clears their browser data between the commit and reveal steps. Applications must carefully manage salt storage and communicate the importance of completing both phases in sequence.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.