Creating Strong Games on Bluff Kingdom: A Creator's Playbook

The Creator's Job in One Sentence

A Bluff Kingdom game is a binary question with a correct answer the creator already knows, locked behind a hash + secret salt and revealed when the game closes. Your job as the creator is to ask a question people want to weigh in on, fund a pool that matches the demand, and commit to a closing time that makes the answer knowable.

Everything else — the cryptography, the fee math, the payout distribution — is handled by the platform. This guide is about the five things that are actually up to you.

Decision 1: Designing the Question

The question is the headline. It's what shows up in the games list, what shows up in shares, and what every potential player reads before deciding whether to stake. If the question is unclear or boring, the rest doesn't matter.

A strong question is:

• Specific. "Will the home team score in the first half?" beats "Will the home team play well?". One has a defined event, the other is a vibe.
• Resolvable. A neutral observer should be able to look at the outcome and agree, with no argument, which side won. If two reasonable people could disagree about the result, the question needs sharpening.
• Time-bounded. Tied to something that will be settled by your closing time. A question that depends on next year's data won't fit a 24-hour game.
• Five seconds to read. If a player has to re-read your question to understand it, they'll scroll past instead.

Avoid hedge words like "probably", "might", "could end up", or "in general". Hedges make the answer ambiguous, and ambiguous answers can generate disputes that the hash + salt model cannot help with — the fairness layer proves what answer you committed, not whether the question is well-formed.

Decision 2: Picking the Two Outcomes

All Bluff Kingdom games are binary. Two outcomes, no middle ground. The way you label them matters more than first-time creators expect.

Good binary pairs are:

• Symmetric. Yes/No, Higher/Lower, Left/Right, Over/Under. Both options feel like real choices.
• Mutually exclusive. Exactly one of the two has to be true at closing time. No "maybe both", no "neither".
• Exhaustive. They cover every realistic outcome of your question. If a third outcome is possible, your question isn't actually binary.

A common trap is asymmetric labels — "Yes" vs "No, but only if X". If one option has an exception, players sense it and stay away. Prefer two clean choices over a clever-sounding pair.

The token used for stakes is shown on the game screen. Players will see the token before they stake; you don't need to label outcomes with the token.

Decision 3: Choosing the Correct Answer

This is the one decision that's hidden until the game closes. The creator picks the correct answer at creation time. The platform combines that answer with a secret salt and hashes the combination. Only the hash is stored publicly.

When the game closes, the salt is revealed on the result page. Anyone can take each of the two possible answers, combine it with the revealed salt, recompute the hash, and confirm exactly which one was locked in at creation. This is the entire fairness model.

What it means for you:

• Pick the right answer honestly. The hash binds you to it. If you change your mind later, the math will show.
• Make sure the right answer is actually knowable by closing time. If you don't know what answer to pick, the game shouldn't exist yet.
• Treat the salt as a secret. It stays protected until the close. After that, it's revealed automatically by the platform.

If you're new to the cryptographic side, the dedicated post on hash + salt fairness walks through the model in more detail. The point here is that picking the answer is a creator decision, not a platform suggestion.

Decision 4: Sizing the Pool

The funded pool is the maximum total that players can stake against. If you fund 100, players can stake up to 100 combined against your pool before it fills.

The fee model makes pool sizing forgiving:

• The 2% fee applies only to the played amount. If you fund 100 and only 30 of the pool gets played, the fee base is 30, not 100. The fee is then taken at settlement as 2% of what you win.
• The unplayed portion returns in full, with no fee. A pool that doesn't fill is not punished.
• An over-funded pool just ties up your balance until close. You won't lose anything, but you can't use that balance elsewhere in the meantime.

Practical sizing:

If you're brand new and have no signal on demand, start small. A modest first pool gets played, gives you data, and builds your credibility. A giant first pool that doesn't fill teaches you nothing and ties up balance you could be using elsewhere.

Decision 5: Picking the Closing Time

The closing time is when the game stops accepting plays and reveals the answer. Once published, it cannot be changed.

The right closing time is the moment the correct answer becomes publicly knowable. Earlier than that, and you're closing while interest is still active. Later than that, and the game looks stale because the result is already known but the game hasn't settled yet.

Things to think about:

• Is the answer time-bounded? A sports game ends. A weather event resolves by a specific date. A market closes at a specific hour. Use the actual settlement moment as your anchor.
• Is your audience awake? Closing at 4 AM in your audience's timezone leaves the result hanging until people wake up. Pick a closing time that matches when the game will get attention.
• How long do you want plays to come in? A 24-hour window gives organic discovery a chance. A 2-hour window concentrates urgency. Both are valid for different question types.

Once you publish, the closing time is locked. The game closes on its own at that moment — no one can close it early or hold it open.

After Publishing

You don't have a creator-side action to take after publishing. The platform handles:

• Accepting player stakes up to the funded amount.
• Tracking the played amount per side.
• Closing the game at the closing time.
• Revealing the salt and computing payouts.
• Returning the unplayed remainder of your pool, with no fee.
• Crediting your share of the result based on which side won.

Your job is to build the game well at the start. If you did, the rest runs itself.

Common Creator Mistakes

A few patterns we see again and again.

Vague questions

"Will the team play well?" — well by what measure? Players can't stake on undefined criteria. Always tie the question to something binary and observable.

Asymmetric outcomes

"Yes" vs "No, unless the manager subs out the goalkeeper". If one option carries an exception, players notice and stay away. Both outcomes should be clean.

Pool size mismatched to demand

Funding 1000 for a niche question that only drew 30 of staking is fine — the unplayed portion returns with no fee — but it locks your balance until close. Funding 30 for a popular question fills in minutes and frustrates late arrivals.

Closing time too early

Closing before the answer is publicly knowable creates disputes the fairness layer can't resolve. The hash + salt proves what you committed; it doesn't prove which option is "really" true.

Closing time too late

Closing long after the answer is settled makes the game look stale and reduces last-minute play. Match the closing time to the information event, not to the calendar.

Treating the salt as something you control

The salt is generated and protected by the platform. You pick the answer; the platform handles the salt and the hash and the reveal.

Frequently Asked Questions

Can I edit a game after publishing? No. Once published, the question, outcomes, hash, closing time, and funded pool are locked. The game closes automatically at its end time. This immutability is what makes the fairness model work.

What happens if no one stakes against my game? You get the entire funded pool back when the game closes, with no fee. Only the played amount is subject to the 2% creator fee.

Can I create demo games to test ideas first? Yes. Demo games behave like real games but use no funds. They're the right place to test pool sizing, closing time, and question phrasing before you commit real stablecoins.

What if I made a mistake on the correct answer? The hash binds the answer you picked. There is no edit path. If the answer was genuinely wrong, contact support — but the fairness model works because the answer can't be changed after publishing, so expect to live with what you committed.

Do I have to fund the pool in the same token as players will stake? Yes. The token a creator funds with is the token players stake in. A USDC pool takes USDC stakes; a USDT pool takes USDT stakes. There's no in-app conversion mid-game.

Can I fund a pool larger than my balance? No. The funded amount is held from your balance at creation. If you don't have it, you can't fund it.

Where to Go Next

For the underlying fairness layer, Provable fairness with hash + salt explains the cryptography. For the fee math behind your pool returns, Stakes, pools, and the 2% fee model covers the worked examples. And the help center is the canonical reference for current creator rules.