Demo · In development Launch app
Placeholder ticker · no token exists

Prove you hold at least X. Show nothing more.

Try the working demo Read the docs View source
// the public scalepass / fail only
COMMITTED X THRESHOLD
Awaiting a proof
Tilt is fixed-size: it shows the answer, never the weight.
// working demo

Commit. Ask. Learn one bit.

SHA-256 · ECDH P-256 · HKDF · AES-GCM · ECDSA P-256 — all via Web Crypto

Prover private

Only you see this side. Edit the numbers, then commit.

—
Balance changed since the last commitment — commit again.
Commitment = SHA-256("atleast/v1|" + balance + "|" + nonce). Computed here, in your browser.

Public view everyone

Everything a verifier, an indexer, or an onlooker would see.

not committed yet
no proof requested
The sealed opening is AES-GCM ciphertext addressed to the verifier. The public cannot read it. The balance appears nowhere on this side.

Verifier · ask “is it at least X?”

One click runs the whole protocol below, with real key exchange, encryption, hashing and signing.

1 Challengefresh 128-bit random value
2 Sealprover encrypts opening to verifier
3 Opensandbox checks hash = commitment
4 Comparebalance ≥ X, one boolean out
5 AttestECDSA signs the boolean
Verifier sandbox log (this box sees the opening; it discloses only the boolean) idle
// how it works

What stays hidden, what is public.

The demo above is a commit-then-attest model. It shows the shape of the idea, “reveal a yes/no, not the number”, using real primitives. It is not a zero-knowledge proof, and the next section says exactly where it falls short.

Hidden from the public

  • Your balance, as a number.
  • The blinding nonce.
  • The plaintext opening. It travels only as AES-GCM ciphertext to the verifier.

Visible to the public

  • The SHA-256 commitment: a binding fingerprint that cannot be reopened to a different balance.
  • The threshold X, the challenge, and the sealed ciphertext.
  • One boolean plus the verifier's ECDSA signature over (commitment, X, challenge, boolean).
  1. Commit. You hash your balance with a random nonce. Hash binding means you can't later claim a different balance; the nonce hides it from guessers.
  2. Challenge. The verifier names a threshold X and a fresh random challenge so old answers can't be replayed.
  3. Seal. You run ECDH against the verifier's public key, derive an AES-GCM key through HKDF, and encrypt your opening. The commitment, X and challenge are bound in as authenticated data.
  4. Open and compare. The verifier's sandbox decrypts, recomputes the hash, rejects any mismatch with the commitment, then evaluates balance ≥ X.
  5. Attest. Only the boolean leaves, signed with ECDSA. Anyone can check that signature against the verifier's public key.
PropertyThis demoA production range proof (e.g. Bulletproofs)
Who learns the balance?The verifier's sandbox sees it in the clear. You must trust it.Nobody. The verifier learns only that the statement is true.
SoundnessRests on trusting the verifier's signature.Rests on cryptographic hardness. Anyone can check the proof with no trusted party.
CommitmentSHA-256 hash (binding, not additively homomorphic).Pedersen commitments (hiding, homomorphic) so “balance − X ≥ 0” can be proven in range.
VerificationCheck one ECDSA signature.Check a short proof of the range statement.

Plainly: a real zero-knowledge range proof would replace the verifier's sandbox with a Bulletproofs-style proof that the committed value lies in a range, checkable by anyone. This page does not do that. It is an illustrative model of the idea.

Known limitations — please read

  • This is not a zero-knowledge proof. The verifier's sandbox learns your exact balance and you must trust it to discard it. A production version would use a ZK range proof (Bulletproofs); this page only models the idea.
  • The verifier here is the same page. Both roles run in your tab, so nothing about the trust model is demonstrated by separation. The log is an honest description, not a security boundary.
  • Repeated questions leak. Every yes/no reveals one bit. Many thresholds recover the balance by binary search.
  • Without a nonce, small balances are guessable. The attacker button above shows this for a bounded range of values.
  • Reduces linkability, not anonymity. A balance proof does not hide who you are, when you transact, or what you did on-chain.
  • Unaudited, demo-only. No third-party audit exists. Nothing here touches mainnet or real funds. Balances are made-up integers.
  • Use lawfully. You are responsible for complying with the laws and tax rules that apply to you.