Stack.bet uses a first-party commitment-and-reveal process for completed rounds. A hidden server value is committed before play, revealed after the round finishes, and checked together with the client seed, nonce, stored placements, and the rules used for that round.
The parts of a completed-round proof
A Stack.bet round proof brings together several values with different purposes. They should not be treated as interchangeable.
Value | Purpose | When it is available |
|---|---|---|
Server seed | The hidden server value used as the HMAC key for generated round values. | Revealed in the proof after the round finishes. |
Server-seed hash | A SHA-256 hash that can later be compared with the revealed server seed. | Committed before the round. |
Client seed | A client-side input included in commitment and HMAC calculations. | Recorded with the round. |
Nonce | A non-negative round input that separates the calculation context. | Recorded with the round. |
Commit hash | A SHA-256 commitment to the server-seed hash, client seed, and nonce. | Attached to the round before play. |
Placements and rules | The authoritative offsets, grades, results, and configuration replayed later. | Completed as the round progresses and finishes. |
The “server seed” here is game-proof data. It is not a crypto-wallet seed phrase, private key, password, or recovery phrase. Stack.bet support should never need a wallet seed phrase to investigate a round.
What is committed before the round
Stack.bet first hashes the hidden server seed with SHA-256. It then creates the round commit hash from the server-seed hash, client seed, and nonce, joined in that order with colon separators.
Server-seed hash = SHA-256(server seed)
Commit hash = SHA-256(server-seed hash : client seed : nonce)
Publishing the commitment before play gives the verifier a fixed earlier value to compare with the later reveal. Changing the revealed server seed, client seed, or nonce would change the calculated hashes and produce a mismatch.
Why the server seed stays hidden during play
The raw server seed is the secret key for the HMAC calculation used to generate the bust value for each tile. Revealing it before the round finished would expose information needed to calculate those values in advance. The commitment exposes a hash instead, allowing the later seed to be checked without revealing it during the live round.
A proof is therefore available only after the round has reached a finished state and its terminal data has been recorded. A commit hash visible during play is evidence of the earlier commitment, not a complete proof by itself.
How to verify a completed Stack.bet round
Open a finished round and keep its round ID and commit hash.
Use the round’s Verify action or open the homepage fairness verifier.
The verifier loads the proof and the exact stored configuration for that round.
It hashes the revealed server seed and compares it with the recorded server-seed hash.
When supplied, it recalculates and checks the round commit hash.
It replays each stored placement in order under the historical round configuration.
It reports Verified only when the seed check and placement replay remain consistent.
The replay compares the recorded tile, grade, axis, offset, bust chance, growth, multiplier, amount change, and survival result. It stops after a terminal bust, just as the original round does.
Go to the Stack.bet fairness verifier to check a finished round. A valid round ID is required; the commit hash provides an additional commitment check.
How placement and generated randomness fit together
For the generated bust value, the current engine runs HMAC-SHA256 with the server seed as the key and a message containing the client seed, nonce, tile number, and the purpose label bust.
Bust HMAC message = client seed : nonce : tile : bust
HMAC key = server seed
That generated value is only one part of an attempt. The game service separately evaluates the accepted placement intent against authoritative tile motion, calculates the placement offset, and assigns the grade. The grade affects placement pressure, while the HMAC value is compared with the calculated bust chance.
The verifier reuses the recorded authoritative offsets rather than pretending that seed data alone determines placement quality. Read how placement grades affect bust risk for the grade and pressure calculation.
What to do if verification reports a mismatch
A mismatch means at least one supplied or stored value did not reproduce the expected hash or placement replay. It does not identify the cause by itself. First confirm that the round has finished and that the round ID and commit hash belong to the same round.
If the mismatch remains, preserve the round ID, displayed result, approximate time, and the verifier details, then contact Stack.bet support. Do not share account passwords, wallet private keys, or wallet seed phrases. Support can investigate a game round using its product identifiers.
What first-party verification does not prove
It does not constitute an independent security or randomness certification.
It does not prove that every network, timing, interface, or account-security behavior is fair.
It does not prove platform solvency, licensing status, or regulatory compliance.
It does not make a real-money round safe or guarantee a favourable result.
It does not show that a future round will reproduce a previous outcome.
The verifier answers a narrower question: whether the revealed seed and stored placement transcript reproduce the recorded completed round under its historical rules. Review the game and risk disclosures for separate product-risk information.
Methodology and change control
This article was reviewed on against the backend commitment and proof services, the game-service HMAC and replay implementation, the historical-configuration lookup, and the public web verifier. It describes the current first-party implementation and does not claim an external audit.
Any change to the commitment format, hash or HMAC algorithm, seed lifecycle, placement authority, proof fields, replay comparison, historical configuration, or verifier interface requires technical review and a new last-reviewed date.