Provable Fairness on Bluff Kingdom: How Hash + Salt Verification Works

Why This Matters

Online betting platforms have a long history of "trust us" claims about fairness. The pattern usually goes: a platform says it doesn't peek at your moves, doesn't change results after the fact, and uses some form of cryptography to prove it. Most of the time, "the cryptography" is either invisible to users or impossible to actually verify.

Bluff Kingdom takes the opposite approach. The fairness mechanism is small enough to explain in a paragraph, the inputs are public after the game closes, and there's a built-in Verify page that does the math for you. If you don't trust the platform, the cryptography is the bridge that makes the platform usable anyway.

This post walks through how it works, why it works, and how to use the verification page yourself.

The Mechanism in One Paragraph

When a creator publishes a game, they pick the correct answer privately. That answer is combined with a randomly generated secret salt and hashed. The hash is stored publicly on the game page from the moment the game is published. The salt is kept private while the game is live so the answer can't be inferred. When the game closes, the salt is revealed and the result page shows both the original hash and the salt. Anyone can take each possible answer, combine it with the salt, and recompute the hash. Whichever option's recomputed hash matches the original was the answer locked in at creation time.

That's the whole mechanism. Every detail below expands on something in that paragraph.

What a Hash Is, In One Pass

A hash function is a one-way mathematical function. You feed it some input, it gives you a fixed-length output. The output looks random and has two important properties:

1. Same input, same output. Hashing "Yes" + a_specific_salt will always produce the same hash. That's what makes verification work.
2. Output reveals nothing about the input. Given only the hash, you cannot recover the original input. That's what makes the commitment secret while the game is live.

The combination of these two properties is what makes hash + salt a useful commitment scheme. The creator can prove what the answer was later (because the hash is reproducible), but no one can guess the answer in the meantime (because the hash leaks nothing).

Why the Salt Matters

You might wonder: why not just hash the answer? Why mix in a salt?

Because there are only two possible answers in a binary game. If a game asks "Higher or Lower?" and the hash is just hash("Higher"), an attacker can compute hash("Higher") and hash("Lower") ahead of time and read the answer off the public hash immediately. Two possible inputs, two possible hashes — game broken.

The salt expands the possible inputs to roughly any random byte sequence. With a fresh, random salt per game, the attacker can compute hash("Higher" + your_specific_salt) only if they already know the salt — but the salt is hidden until the game closes. This is what makes the commitment actually hide the answer.

This is why every game on Bluff Kingdom uses a freshly-generated salt. Reusing salts would break the property.

The Lifecycle, Step by Step

A more detailed walkthrough of what happens at each stage.

At creation

1. The creator selects the correct answer in the game-creation flow.
2. Bluff Kingdom generates a fresh secret salt for the game.
3. The platform computes hash(correct_answer + salt).
4. The hash is stored publicly on the game record.
5. The salt is stored privately, encrypted, and tied only to this game.
6. The funded pool is locked. The end time is locked. The game is published.

From this moment forward, the answer cannot change. Any future attempt to reveal a different answer would produce a hash that doesn't match the stored one, and the verification page would expose it.

While the game is live

• Players see the question, the two possible answers, the funded pool, the closing time, and the public hash.
• Players cannot see the salt, so they cannot guess the correct answer by recomputing hashes.
• Plays accumulate on both sides until the closing time arrives or the pool fills.

When the game closes

1. The closing time is reached (or the pool fills).
2. Bluff Kingdom decrypts the stored salt and publishes it on the result page alongside the original hash.
3. Winners are paid out automatically based on the now-revealed answer.
4. The Verify link becomes visible on the game page.

The verification step

Anyone can independently confirm the answer was the locked-in one:

1. Open the Verify link on the result page.
2. The page shows the original hash, the revealed salt, and a control to pick which possible answer to test.
3. Choose Answer A. The page recomputes hash("Answer A" + salt) and compares it to the original hash.
4. Choose Answer B. The page recomputes hash("Answer B" + salt).
5. Whichever option's recomputed hash matches the stored original is provably the answer that was locked in at creation.

This verification doesn't require trusting Bluff Kingdom. The hash function is standard, the salt is now public, and the comparison is deterministic. You could do the same calculation in any programming language and get the same answer.

What This Mechanism Stops

The hash + salt commitment defends against a specific set of attacks. It's worth being clear about which.

• Creators changing their mind after seeing how players bet. A creator who funded a pool, watched stakes pile onto one side, and wanted to flip the correct answer to the other side can't — the hash was committed before any plays.
• The platform retroactively rewriting outcomes. The same logic applies to Bluff Kingdom itself. We cannot publish a salt + answer combination that produces a different hash than the one we stored.
• Disputes about "what the answer was supposed to be". The hash is the source of truth. Either an answer's recomputed hash matches the original or it doesn't.

What This Mechanism Doesn't Stop

A few honest limits:

• Bad descriptions. If the creator's description is ambiguous, players can disagree about which answer should have been correct. The hash protects the creator's commitment; it doesn't fix ambiguity in the question.
• Out-of-band knowledge. If a creator knows the outcome with certainty before publishing (insider knowledge, a result that's already public), the hash doesn't protect players from that. It only protects against changes after the game opens.
• Player mistakes. A play that staked the wrong side because the player misread the question is still a losing play. Hashes don't fix typos.

These are problems of game design and player diligence, not of the fairness mechanism. The mechanism does what it says: locks the answer at creation, lets anyone verify after close.

Why This Beats "Trust Us"

Plenty of platforms could announce results without any cryptography and the results would still be correct most of the time. The point of the hash + salt mechanism isn't that other approaches are usually wrong — it's that you don't have to take anyone's word for it. The public hash before play and the public salt after close give every player and every observer a way to confirm the result independently.

That property has a real economic effect: strangers are willing to take the other side of binary games on Bluff Kingdom in part because the math works out, regardless of who's running the platform.

How to Use the Verify Page

Concrete steps next time you finish a game:

1. Open the game page after it closes. The status will show the final result.
2. Look for the Verify link near the result.
3. The page will show: the original hash, the revealed salt, the two possible answers.
4. Click each answer. The page recomputes the hash with that answer + the salt and shows whether it matches the original.
5. Exactly one will match. That's the answer that was locked in.

If neither matched, something would be wrong — and that's the entire point. The mechanism makes any tampering detectable.

Frequently Asked Questions

Can the platform peek at the salt early? The salt is stored encrypted and tied to the specific game. It's only decrypted when the closing time fires. There's no UI or API exposing it earlier.

What if the creator loses access to their account before the game closes? The salt is held by the platform, not the creator. Account loss does not affect the game's ability to close and resolve.

Could a hash collision rig a game? Hash collisions are computationally infeasible for the hash function in use. Finding two distinct (answer, salt) pairs that hash to the same value is not practical with current or near-future computing.

Why don't I see the salt while the game is live? By design. If the salt were public, anyone could compute hash("Answer A" + salt) and hash("Answer B" + salt) and read the correct answer off the game page. Hiding the salt is what hides the answer.

Is the verification page the only way to verify? It's the easiest, but no. With the original hash and the revealed salt, you can recompute the hash in any programming environment yourself. The verification page just makes it convenient.

Where to Go Next

For a wider tour, the beginner's guide covers how this fairness model fits with the rest of the platform. For the gameplay implications, How binary games work walks through the lifecycle of a single round. The provably fair page is the in-app summary of the same mechanism with live examples.