Commit-Reveal

Commit-Reveal Explained in Detail

Commit-reveal is a two-step pattern. First, a user submits a commitment, usually a hash of a value plus a secret salt. Later, the user reveals the value and salt so the contract can verify the commitment.

The goal is to prevent other users from copying or reacting to the value before it is locked in.

Smart contract example

A sealed-bid auction can store a commitment first:

bytes32 commitment = keccak256(abi.encode(bidAmount, salt));

During the reveal phase, the bidder submits bidAmount and salt. The contract recomputes the hash and checks that it matches the stored commitment.

Commit-Reveal in Auditing

Commit-reveal can reduce front-running, but small design mistakes can make the scheme ineffective. The reveal phase, deadlines, salts, deposits, and non-reveal behavior matter as much as the hash.

If missing reveals are not penalized or handled, users can reveal only when the outcome benefits them.

Red flags in code

• Commitment uses abi.encodePacked with ambiguous dynamic fields.

• Salt is small, predictable, or reused.

• Commit and reveal windows overlap incorrectly.

• No deadline or phase transition enforcement.

• Users can reveal someone else's value for advantage.

• No handling for users who commit but never reveal.

• Revealed value does not include sender, chain, or contract context when needed.

How to test or review it

• Test early reveal, late reveal, duplicate reveal, wrong salt, wrong sender, and missing reveal.

• Check whether the commitment binds to the user and contract when needed.

• Verify phase transitions cannot be skipped or extended by an attacker.

• Use the Keccak-256 tool to reproduce simple commitments during review.

• Consider whether MEV risk remains during the reveal phase.