The Verify Page in Practice: Confirming a Bluff Kingdom Result

What the Verify Page Does

The Verify page is a public tool. It takes three inputs and produces a yes-or-no answer:

• The original hash — the cryptographic commitment stored when the game was created.
• The revealed salt — the secret value that was combined with the correct answer to produce the hash. Revealed at close.
• A candidate answer — one of the two possible outcomes for the game.

It computes the hash of (candidate answer + salt) and compares it to the original hash. If they match, the candidate answer is the one that was committed at creation. If they don't, it isn't.

That's the entire mechanism. There's nothing else hidden, no additional inputs, no proprietary algorithm. The math is the fairness.

Why It Works

The fairness model relies on three properties of cryptographic hash functions:

1. Determinism. Hashing the same input always produces the same output. So the same (answer + salt) input always recomputes to the same hash.
2. Pre-image resistance. Given a hash, you can't practically compute what input produced it. So while the salt is hidden, the answer can't be inferred from the hash.
3. Collision resistance. It's practically impossible to find two different inputs that produce the same hash. So if your candidate answer + the salt produces the original hash, no other answer could have.

Combine these with the platform's commitment to revealing the salt at close and not before, and you get a one-way commitment that's impossible to fake post-hoc.

Step by Step: Verifying a Closed Game

Here's the actual user flow.

1. Open a closed game

Go to a game whose closing time has passed. The result page shows the original hash, the revealed salt, the correct answer, the played amounts on each side, and the payouts.

2. Click the Verify link

On the result page, the Verify link opens the verification page with the hash and salt pre-filled.

3. Pick a candidate answer

The verifier lets you pick either of the two possible outcomes. Pick one to start — it doesn't matter which; you're going to check both.

4. Run the verification

The page computes the hash of (your candidate answer + the revealed salt) and compares it to the original hash.

• If it matches, the candidate answer is the one the creator committed at creation.
• If it doesn't match, it's the other answer that was committed.

5. Try the other answer

Switch the candidate to the other outcome and run the verification again. One of the two should match the original hash. The one that matches is the locked-in correct answer.

6. Confirm against the result

Compare the answer that matched the verification to the answer the result page declared correct. They should be the same. If they were anything other than the same, the result page is wrong — and that's the kind of disagreement the verifier exists to surface.

In practice, they'll always be the same. The platform uses the same hash + salt to settle the game internally, so a successful verification just confirms the math everyone is using lines up.

What a Successful Verification Proves

A match proves a specific, narrow thing:

The candidate answer + the revealed salt produces a hash that equals the original hash stored when the game was created.

By the properties of the hash function, this means:

• The candidate answer was the one committed at creation.
• The committed answer was not changed between creation and close.
• The correct answer the platform used to settle the game is the same one that was committed.

That's a strong guarantee. It rules out tampering by anyone — the creator, the platform, an attacker — who could have wanted the answer to be different between creation and close.

What Verification Does Not Prove

Verification is precise, but it's also narrow. It does not prove:

• That the question was well-formed. A verified hash on a vaguely-worded question is still a verified hash on a vaguely-worded question. Bad questions create disputes the verifier can't resolve.
• That the creator picked the "right" answer in the real world. The verifier confirms which answer was committed; it doesn't judge whether that answer is true. If a creator mis-classified the outcome (claimed Yes won when actually No happened), the verifier will still confirm whatever was committed.
• Anything about other games. Verification is per-game. Each game has its own hash, its own salt, its own commitment.

The fairness model handles tampering. Disputes about the substance of the result are a different kind of problem — one the platform addresses with creator reputation, support review, and the practical discipline that comes from games being immutable.

When Should You Verify?

For most players, the answer is: rarely. The fairness model holds because anyone can verify, not because everyone does. The platform doesn't change behavior based on whether you click Verify.

That said, verifying is worth doing:

• The first time you play. It builds intuition for what the hash and salt actually are.
• On a game with a result that surprised you. If the answer was unexpected, the verifier confirms it was committed from the start rather than picked after the fact.
• On a high-stakes game where the outcome involved a large pool. Verification cost is constant; the stakes that justify it are personal preference.

The point is that verification is available to anyone. The discipline of the system comes from that availability, not from mandatory checks.

Common Misconceptions

A few patterns we see often.

"If I can't verify, the platform must be hiding something"

Actually, verification is fully public. The Verify link is on every closed game's result page, and the standalone fairness page at /provably-fair explains the model with its own verifier. If you can't verify, it's a UX issue, not a transparency issue.

"The hash proves the creator was honest about reality"

It doesn't. The hash proves the creator's committed answer didn't change between creation and close. Whether the committed answer matches reality is a question of game quality and creator reputation, not cryptography.

"I need to be technical to verify"

No. The Verify page does the math for you. You pick a candidate answer; the page tells you whether it matches the hash. There's nothing to compute by hand.

"Verification is only for the post-close moment"

The hash is public the entire time the game is live, so you can save it. After close, the salt becomes public too, and you can verify whenever you want. The verifier works on closed games indefinitely.

Frequently Asked Questions

Where is the original hash shown? On the game page (while live) and on the result page (after close). The hash doesn't change.

When is the salt revealed? At the closing time. Before that, it's protected; after that, it's public on the result page.

What if neither candidate answer matches the hash? That would be a serious issue — it would mean the answer that was committed is neither of the listed outcomes. Contact support immediately if this ever happens. In practice it doesn't, because the same hash + salt is used to settle the game internally.

Can I verify a game that hasn't closed yet? You can confirm the hash exists, but you can't run the verification without the salt — and the salt isn't released until close.

Can the platform regenerate the salt for a game in flight? No. The salt is committed to a specific game at creation. Changing it would change the hash, and the original hash is what's stored publicly.

Does verification work the same for USDC and USDT games? Yes. The fairness model is identical regardless of the token used.

Where to Go Next

For the deeper cryptographic context, Provable fairness with hash + salt explains the model in more detail. For why the underlying immutability is the load-bearing rule, Why games can't be edited or deleted covers the design choice. And the public fairness page has the standalone verifier you can try on any closed game.