Provably fair overview

Every game result at My Crypto Casino is produced by a commit-reveal scheme combined with Solana chain entropy, executed by the on-chain program. That means two things for you as a player:

1. The result cannot be changed after the fact. The operator locks in its contribution (a secret value) before play, by publishing a cryptographic fingerprint of it on-chain. Later, the program refuses to settle unless the revealed secret matches that fingerprint exactly.
2. You can check everything yourself. All the inputs and the exact formula are public. After any round or bet, you can recompute the result from on-chain data and compare it with what the game paid.

This page explains the scheme in plain words. The per-game pages give the exact formulas, and Verify a round walks you through checking a real round step by step.

​

What is provably fair built from?

A committed secret. Where a result must stay hidden during play (Crash, Mines), the backend generates a random 32-byte secret and publishes its SHA-256 hash (the commitment) on-chain before play begins. A hash works like a sealed envelope: it reveals nothing about the secret, but once published, only that exact secret can match it. When the secret is revealed at the end, the program itself hashes it and rejects the transaction if it does not match the commitment. Solana chain entropy. The result never depends on the secret alone. It also mixes in a slot hash: the hash of a recent Solana slot, read by the program from Solana’s SlotHashes sysvar at a defined moment. This value is produced by the Solana network, not by the casino, and does not exist yet when the commitment is made. A public, deterministic formula. The result is a fixed mathematical function of those inputs. The same function runs inside the on-chain program (the backend cannot misreport a result; the program computes it), and it is published on these pages so you can run it yourself.

​

How does a round flow, step by step?

Dice compresses this flow into a single transaction: it has no hidden state to protect, so there is no operator secret at all. The roll is derived from the slot hash, your account and your bet counter, and settled in the same instruction that draws it.

​

What each game commits, and when

​

What this guarantees, and what it assumes

Honesty matters more than marketing here, so let’s be precise. This scheme is commit-reveal with public chain entropy, not a VRF (verifiable random function). Here is the exact boundary between what is enforced by code and what relies on the operator behaving.

​

Enforced by the on-chain program

• No outcome swaps after commitment. The program hashes the revealed secret and rejects any settlement where it does not match the published commitment. The operator cannot pick a different secret after seeing how a round is going.
• Entropy the operator does not produce. The slot hash comes from the Solana network. It is unknown when the commitment is published, and the casino does not create it.
• Results computed on-chain. The crash point, the dice roll and the mines board are computed (or re-derived and checked) by the program itself. The backend cannot report a result the formula does not produce.
• Full public auditability. Every round and bet emits on-chain events carrying all the derivation inputs and the outcome. Anyone, not just the player involved, can recompute every historical result.

​

Assumed: the honest caveats

• Timing influence. The operator’s backend chooses when to submit certain transactions, which gives it partial influence over which slot hash gets captured. Each per-game page spells out exactly what this could and could not achieve for that game.
• Cancels are possible, but refund-only. The operator can void a crash round or a mines game. A void always refunds every stake in full (the program has no way to confiscate through a cancel), and every void is publicly logged, so the cancel frequency is auditable by anyone. Frequent cancels would be the visible on-chain signature of a misbehaving operator.
• The Mines board is known to the operator during play. This is structural: tile reveals are served instantly off-chain, and whoever serves them must know the board. The commitment guarantees the board was fixed before your first pick and cannot be rewritten afterwards. See Mines fairness for exactly how that is enforced.

​

Why accept these trade-offs?

Because they are the price of instant, seamless gameplay, not shortcuts. Each game sits exactly where it has to on that spectrum:

• Mines: serving a tile reveal in milliseconds structurally requires a party that already knows the board. The alternatives (an on-chain transaction per click, or an oracle round-trip per reveal) would turn every tile into a fee and a wait. An operator who knows the board is indispensable to a Mines that feels instant and still settles on-chain; the commitment scheme exists to box in what that knowledge can do.
• Crash: a shared live round needs someone to drive it for all players at once. That is a pragmatic choice rather than a structural necessity, which is why the program ships with a built-in migration path to oracle-based randomness (VRF), a future phase that would remove the timing caveats where the economics allow it.
• Dice: the other end of the spectrum. There is nothing to hide during play, so there is no operator secret at all. Where removing operator trust costs nothing, the design removes it.

In short: the operator runs the games, and the chain makes cheating either impossible (anything after the commitment) or publicly detectable (timing patterns, cancel frequency, win-rate statistics).

​

Verify it yourself

• In the app, every finished Crash round exposes its fairness data (the revealed secret, the block hash, and links to the on-chain transactions) in the round details, along with a one-click fairness tool.
• Dice and Mines publish every derivation input in the settlement event of the bet’s own transaction.

Verify a round walks through the whole process, from the in-app data to recomputing the result with a few lines of code.