// commit & reveal

Commit now.
Reveal later.
Prove you never changed your mind.

Status: Ticker (placeholder, no token exists):
// the working demo

Seal it. Reveal it. Check it.

Real SHA-256 through the browser's Web Crypto API and real random nonces from crypto.getRandomValues. Nothing is sent anywhere.

1 Seal a value

Type anything — a bid, a guess, a prediction. The app draws a fresh 256-bit random nonce and publishes only commitment = SHA-256(value ‖ nonce).

Demo keys only — never paste a real seed phrase or private key. Use throwaway text; this value is shown again when you reveal it.

2 What the world sees

This is everything an observer (or a blockchain) would hold while you wait. The value and nonce are not in it, and cannot be recovered from the hash.

Public commitment
Nothing sealed yet.

3 Reveal

When the time comes, publish the original value and the nonce. Nothing else is needed.

4 Anyone can verify

The verifier recomputes SHA-256(value ‖ nonce) and compares it to the commitment from step 2. Change anything — even one character — and it breaks.

Reveal first.

5 Why the random nonce matters

If you committed with no nonce — just SHA-256(value) — anyone could hash likely guesses and compare. Give an attacker a guess list and see what happens.

// how it works

What's hidden vs. what's public

Public at commit time

  • The 32-byte commitment hash
  • That some value was fixed at that moment (the timestamp or block it was recorded in)
  • The scheme: SHA-256 over value bytes followed by a 32-byte nonce

Hidden until reveal

  • The value itself — SHA-256 is one-way
  • The 256-bit random nonce, which stops guess-and-check attacks
  • Nothing about the value's length or content leaks from the hash
  1. Hiding. Because the nonce is 256 bits of fresh randomness, the commitment looks random whatever the value is — even a one-bit answer like “yes”.
  2. Binding. To open the commitment to a different value, you'd need another input with the same SHA-256 output — a collision or second preimage, which is computationally infeasible. So you can't change your mind after committing.
  3. The nonce is fixed-length (32 bytes) and appended last, so value ‖ nonce can't be re-split into a different valid pair. Variable-length schemes should length-prefix each field.
  4. On Solana, a program can store a commitment in an account and later check a revealed value with its native SHA-256 syscall — the same function used here. No curve is involved, so there is no P-256-versus-ed25519 caveat for this primitive.

Known limitations — please read

  • Not anonymous. A commitment hides the value, not who published it or when. The committing account and timing are public.
  • You can refuse to reveal. Binding stops you changing the value, but not walking away. Real protocols add deadlines and deposits or penalties for non-reveal.
  • Lose the nonce, lose the opening. If you forget the value or nonce, nobody (including you) can open the commitment. This demo keeps them only in this tab's memory — reloading erases them.
  • Weak nonces break hiding. Hiding depends on the nonce being truly random and secret. Reusing or leaking a nonce lets attackers test guesses — step 5 shows why.
  • Timing order is not enforced by the hash. “Committed earlier” is only meaningful if the commitment is recorded somewhere with a trustworthy timestamp (e.g. a blockchain slot). This page records nothing anywhere.
  • Teaching demo, not production code. Unaudited; no on-chain component, token, or service exists behind this page.