A verifiable onchain game should expose the committed inputs, result source, calculation and settlement record needed to reproduce the outcome without trusting a screenshot.
Onchain can describe several different designs
A casino may use the chain only for deposits, for wager settlement, for randomness inputs or for the full game program. These are materially different fairness claims.
Identify the program, transaction and offchain dependencies before describing a game as fully onchain.
The result inputs must be committed in time
A fair verification process prevents either side from selecting a favourable input after learning the other input. The interface should show when values were committed and how the final result combines them.
A hash is useful only if the later disclosed value matches it and the calculation can be repeated.
Reproduce the result independently
Record the transaction signature, block or slot reference, game inputs, algorithm version and result mapping. Recalculate the outcome rather than accepting a green verified label.
If an external block or oracle supplies randomness, check the precise selection rule and whether the operator could choose a different reference after the wager.
Fair results do not remove gambling risk
A correctly generated result can still come from a game with house edge and high variance. Fairness addresses manipulation, not expected profitability.
Operator solvency, withdrawals, KYC and account enforcement remain separate even when each wager is technically reproducible.
Primary sources
- SourceSolana transaction and program concepts
- SourceSolpot fairness interface
- SourceKYCBit provably fair casino guide