A successful verification shows that revealed inputs reproduce an outcome and match a prior commitment. It does not, by itself, prove that the seed was kept secret, the commitment was shown in time or a wallet paid correctly.
What you’ll take away
- Keep the pre-round commitment so it can be compared with the revealed seed.
- Use the exact client seed, nonce and outcome mapping; a correct hash alone is not a full check.
- Hangar generates seeds in the browser, so the demo cannot establish independent server custody.
A commitment comes before the result
Commit–reveal separates a hidden value from a public promise about that value. Before a round, the game publishes SHA-256(serverSeed). After the round, it reveals the server seed. Hashing that revealed seed should reproduce the earlier commitment.
The sequence matters. A hash first supplied after a result is known does not demonstrate that the seed was fixed beforehand. An evaluator needs the commitment as it appeared before the round and the exact inputs revealed afterward. A verification interface should make both available.
Recompute the outcome, not only the hash
Hangar combines the client seed and round nonce into a message of the form clientSeed:nonce, with the server seed as the HMAC-SHA256 key. Updraft converts the first 13 hexadecimal digits of the HMAC to an integer and divides by 2⁵². Its crash mapping then applies the return factor and multiplier cap.
Minefield and Plinko use different mappings from their derived values. Copying the Updraft formula into a Mines verifier would not verify a board layout. A complete check uses the game-specific version of the algorithm that produced the round.
Inspect a fixed example
The following public inputs are reproducible test data, not a live round. These values are calculated from the shared fairness implementation when the site is built.
Server seed: hangar-example-server-seed
Client seed: operator-demo
Nonce: 12
SHA-256 commitment:
140711489dde82d0113ff63473e92f4bc1401d9abffcb9e162b140d9979890a7
HMAC-SHA256:
b191dbe63f30c998dd28db30d7c7f298688f7c862f04d69bba3a4883390bf501
Updraft crash: 3.16×The fairness reference provides a copyable Node.js example using the standard crypto library. Compare the commitment and the result independently. Keep the nonce and punctuation unchanged: a different message represents a different calculation.
Separate four different assurances
| Question | What to inspect |
|---|---|
| Does the seed match? | Recorded commitment versus hash of revealed seed |
| Does the result match? | Exact inputs and game-specific mapping |
| Was the seed protected? | Where it was generated, stored and revealed |
| Was the payout correct? | Stake, settlement rules and wallet ledger |
In Hangar, the first two can be demonstrated locally. Seeds and results still originate in the browser, so this is not independent custody or production certification. Server-controlled rounds, protected seeds and auditable settlement are separate engineering tasks.
Sources & scope
Prepared from the Hangar project’s implementation and documentation. Source links point to the inspected revision, so the examples remain traceable as the project changes. These notes describe a software demo, not a certified real-money service.