Abstract

Sealed-bid auctions require that bids remain hidden from other participants until all bids are submitted. On a transparent blockchain, every transaction is visible before it is finalized, making naive on-chain sealed-bid auctions trivially gameable. Commit-and-reveal schemes address this by splitting the auction into two phases: a commitment phase where bidders submit a hash of their bid, and a reveal phase where they open their commitments. This article examines the cryptographic requirements for correct commit-and-reveal auctions, the failure modes that break secrecy or fairness, and how ZK proofs can extend the model to eliminate the reveal phase entirely.

The Commit Phase

In the commit phase, each bidder computes a commitment C = Hash(bid

nonce) and submits C on-chain. The hash binds them to their bid without revealing it. The nonce is essential: without it, an observer can brute-force the commitment by hashing plausible bid values. For token-denominated auctions with bounded bid ranges, a 128-bit random nonce provides sufficient hiding. The commitment scheme is binding (the bidder cannot change their bid after committing) and hiding (the commitment reveals nothing about the bid) assuming the hash function behaves as a random oracle - a standard assumption for Keccak-256 as used in Ethereum contracts.

Practical commit-and-reveal contracts, such as those used in ENS (Ethereum Name Service) domain registration and early NFT Dutch auction variants, implement this pattern directly. ENS uses a commitment hash over the label, owner address, and a secret, with a minimum waiting period between commit and reveal to prevent front-running the commitment itself.

Reveal Phase Failures and Last-Revealer Advantage

The reveal phase introduces a strategic vulnerability: the last bidder to reveal has already seen all other revealed bids and can choose not to reveal if they are losing. This “last-revealer advantage” breaks the sealed-bid property. Mitigations include:

• Deposits with slashing: Require each bidder to post a deposit that is slashed if they do not reveal within the reveal window. This aligns incentives but does not fully solve the problem if the expected profit from withholding exceeds the deposit.
• Forced reveal via time-lock: Bidders encrypt their commitment opening under a time-lock puzzle or a trusted oracle that releases the decryption key after the commit phase ends. The Chainlink VRF and Pyth’s publish-time oracle model are proxies for this, though time-lock encryption remains less deployed.

The ENS registrar avoids this issue because the auction outcome (domain registration) requires the winner to reveal to claim the domain, so non-revelation is self-defeating for the winner.

ZK-Based Sealed Bids - Eliminating the Reveal Phase

A more robust construction uses ZK proofs to eliminate the reveal phase. In a ZK auction, bidders submit a commitment C along with a ZK proof that their bid satisfies validity constraints (e.g., the bid is within bounds and the bidder holds sufficient funds). After the commit phase, a ZK proof of correct winner determination is computed over all commitments, proving that the declared winner holds the highest bid without revealing individual bid values to the chain. The winning bidder’s bid is revealed only implicitly through the settlement transaction.

Projects building ZK auction infrastructure include Aztec Network’s private auction component and research implementations using the Circom/SnarkJS toolchain with Pedersen commitments. The main cost is prover time for the winner-determination circuit, which scales with the number of bidders and the comparison circuit complexity. For auctions with fewer than 1000 bidders, prover time on mid-2025 hardware is under 30 seconds, which is practical for most use cases.

Choosing Between Commit-Reveal and ZK Auctions

Classic commit-and-reveal is simpler to implement, auditable with minimal tooling, and does not require ZK prover infrastructure. It is appropriate when the number of bidders is small, last-revealer risk is manageable through deposits, and bid privacy after auction close is not required. ZK-based auctions are warranted when full bid privacy is a business requirement, the bidder set is large enough to make deposit-based mitigations complex, or the auction is part of a larger privacy-preserving DeFi protocol where composability with other ZK components is valuable.