Why Games Can't Be Edited or Deleted on Bluff Kingdom

The Rule, Stated Plainly

Once a game is published on Bluff Kingdom, it cannot be edited or deleted. That includes:

• The question text.
• The two possible outcomes.
• The answer hash (and therefore the correct answer the creator picked).
• The closing time.
• The funded pool.

The game closes automatically at its scheduled end time. No one — not the creator, not Bluff Kingdom — can close it early or hold it open longer. The result is then resolved using the original hash commitment.

This rule sounds restrictive. It is. And it is restrictive on purpose.

Why Immutability Is the Foundation, Not a Limitation

Bluff Kingdom's fairness model is built on a single cryptographic commitment: at creation time, the creator's chosen correct answer is combined with a secret salt and hashed. The hash is stored publicly. The salt is revealed when the game closes so anyone can verify the original answer was locked in from the start.

Now imagine the alternative: games can be edited after publishing. The creator looks at how players are staking, sees that one side is heavier than the other, and decides to "fix the description" or "clarify the outcomes" in a way that subtly changes the game. Maybe the answer hash gets re-committed in the process.

Players who staked under the original terms now have no way to know which terms they actually agreed to. The hash they verified at the start of the game points to a state that no longer exists. The fairness model collapses, because the cryptographic commitment was never enforced.

The whole point of hashing the answer at creation is that the commitment is binding. You can verify it later because the thing that was committed cannot be re-committed under different terms. Immutability is what gives the hash its meaning.

What Locks at Publish Time

The moment a game is published, the platform records:

• The exact question text the creator entered.
• The two outcomes the creator defined.
• The hash of (creator's chosen correct answer + secret salt).
• The closing time.
• The funded pool amount and the token used (USDC or USDT).

After publishing, the platform's job is to:

• Accept stakes from players up to the funded pool.
• Track the played amount on each side.
• Reach the closing time and stop accepting stakes.
• Reveal the salt and resolve the result.
• Apply the 2% fee on the played amount only.
• Pay out winners and return the unplayed remainder of the pool.

None of those steps require — or allow — the original game terms to change. The platform can't decide to extend the closing time because play is heavy. The creator can't decide to swap outcomes because they want a different distribution. The hash binds everything to the original definition.

What Players Get from Immutability

If you're on the player side, immutability is what makes a stake feel like a real commitment instead of a bet on a moving target.

When you stake on Bluff Kingdom:

• The question you read is the question that resolves.
• The two outcomes you saw are the two outcomes that get judged.
• The closing time you saw is the closing time the game uses.
• The hash you verified is the hash the result is checked against.

You don't have to monitor the game between staking and close to make sure none of the terms shifted. They can't.

What Creators Get from Immutability

If you're the creator, immutability sounds like a constraint, but it's actually a feature.

• Players trust your games more. A game that could be edited mid-flight would be staked against more cautiously. Your game, which can't, is treated as a real commitment.
• Disputes have a clear answer. "Did the creator change the rules?" can always be answered with "no, here's the original hash, here's the salt, here's the verification". Without immutability, every disputed game is a he-said-she-said.
• Your reputation accrues. Creators who consistently ship clear, well-defined games earn returning players. That reputation is built one immutable game at a time.

The cost is that you have to think before you publish. There's no "publish and tweak" loop. Demo mode exists exactly for that.

Demo Mode Is Where You Iterate

Demo games behave like real games — same lifecycle, same hash + salt commitment, same automated close — but they use no funds. The creator-side experience is identical, but no USDC or USDT is involved.

That makes demo the right place to:

• Test how a question reads when it's published.
• See whether players stake on the side you expected.
• Try different closing times and see which generates the most participation.
• Catch ambiguous wording before real money is on the table.

Once your design is solid in demo, publishing the same game for real is a copy-paste of the parts you've already tested.

What If I Made a Mistake?

The honest answer: live with it.

The fairness model works because mistakes can't be retroactively fixed. If a creator could come back and "correct" a typo or "clarify" an outcome, every game becomes negotiable. The platform's promise that the answer was locked at creation depends on the game's terms being locked too.

What you can do:

• For genuine technical issues (a game that didn't close at the scheduled time, a UI bug that affected staking), contact support with the game ID and details.
• For "I would have phrased it differently", the answer is to publish another, better-phrased game. The cost of a poorly-worded game is mainly that fewer players will stake against it. The unplayed portion of your pool returns with no fee.

Why the Closing Time Is Locked Too

People sometimes accept that the answer is locked but want closing time to be flexible. "What if interest is higher than I expected and I want to give the game more time?"

The reason closing time is locked is that the closing time is part of what players stake against. Someone who put down 5 USDC at hour 2 of a 24-hour game made that decision based on the 24-hour window. Extending the window changes the deal they agreed to.

Immutability of closing time is the same principle as immutability of the answer: the commitment has to bind, or the commitment is just suggestion.

Frequently Asked Questions

Why can't I just delete a game I haven't published yet? You can — drafts that haven't been published can still be discarded. The constraint is on published games. Once you click publish, it's locked.

What if my game's question turns out to be ambiguous? The unplayed portion of your pool returns to you with no fee, and players who staked under unclear terms get the result based on the hash. The lesson is to test phrasing in demo mode first.

Can support edit a game on my behalf? No. Support can investigate technical issues, but it cannot rewrite or remove a published game. The fairness model would break if any human could.

What happens to funds in a game that nobody plays? The full funded pool is returned to the creator with no fee when the game closes at its scheduled time.

Is the closing time really automatic? Yes. There's no manual close button on either side. The platform closes the game at the scheduled time, reveals the salt, and resolves the result.

Where to Go Next

For the cryptography that makes immutability binding, Provable fairness with hash + salt walks through the verification flow. For the creator workflow that respects the locked terms, the creator's playbook covers how to set good ones from the start. And the help center is the canonical reference for game lifecycle rules.