Implementing Provably Fair Verification in Mobile Crypto Casino
Provably Fair — mechanism where neither casino nor player can influence outcome after round begins. Not marketing: without correct implementation, system remains fair only in words. Mobile handles client-side commit-reveal and verification UI.
Commit-Reveal Scheme
Standard scheme works like this:
- Before round server publishes
server_seed_hash = SHA256(server_seed). - Client generates
client_seed(random 32 bytes via CSPRNG). - Round result:
HMAC-SHA256(server_seed, client_seed + nonce), where nonce — round counter. - After round server reveals
server_seed. Client verifies:SHA256(server_seed) == server_seed_hash.
Mobile app handles steps 2 and 4.
Client Seed Generation on Mobile
// iOS
var clientSeedBytes = Data(count: 32)
clientSeedBytes.withUnsafeMutableBytes {
SecRandomCopyBytes(kSecRandomDefault, 32, $0.baseAddress!)
}
let clientSeed = clientSeedBytes.map { String(format: "%02x", $0) }.joined()
// Android
val clientSeedBytes = ByteArray(32)
SecureRandom().nextBytes(clientSeedBytes)
val clientSeed = clientSeedBytes.joinToString("") { "%02x".format(it) }
User should be able to change client_seed manually — standard practice for transparent systems. Input field with "Refresh" button (generates new random seed).
Client-Side Verification
After round app displays verification screen. User sees:
| Parameter | Value |
|---|---|
| Server Seed Hash | a1b2c3... (shown before round) |
| Server Seed | deadbeef... (revealed after) |
| Client Seed | f00f... |
| Nonce | 42 |
| HMAC Result | 0x3f2a... |
| Outcome | 6 (from HMAC mod 6 + 1) |
Verification calculation executes locally in app — user sees exactly what's computed. SHA-256 and HMAC-SHA-256 available in CryptoKit (iOS) and javax.crypto (Android) without dependencies.
Additionally: link to third-party verifier (e.g., provablyfair.org/verify) — raises trust even if user doesn't use it.
What to Check
All nonce values for session with one server_seed must produce different results — verify automatically. Seed rotation after N rounds or on user request. On rotation — immediate reveal of previous server_seed and publish new hash.
Timeline — 3–5 days: client_seed generation, HMAC result calculation, verification screen, seed change on request, server compatibility testing.